You are not logged in.
Is it normal for security updates to take several days to show up in Devuan? I am notified when there are security updates for Debian, and I've noticed that it often takes several days for those updates to show up in Devuan.
For example:
- -------------------------------------------------------------------------
Debian Security Advisory DSA-4400-1 security@debian.org
https://www.debian.org/security/ Moritz Muehlenhoff
February 28, 2019 https://www.debian.org/security/faq
- -------------------------------------------------------------------------Package : openssl1.0
CVE ID : CVE-2019-1559Juraj Somorovsky, Robert Merget and Nimrod Aviram discovered a padding
oracle attack in OpenSSL.For the stable distribution (stretch), this problem has been fixed in
version 1.0.2r-1~deb9u1.We recommend that you upgrade your openssl1.0 packages.
For the detailed security status of openssl1.0 please refer to
its security tracker page at:
https://security-tracker.debian.org/tracker/openssl1.0Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://www.debian.org/security/Mailing list: debian-security-announce@lists.debian.org
My amd64 Devuan system received that update today, though it might have been available earlier because that system is in a VM and runs only periodically. However, my i386 Devuan system still thinks that 1.0.2q-1~deb9u1 is the latest version of that package:
$ aptitude upgrade libssl1.0.2 -s
libssl1.0.2 is already installed at the latest version (1.0.2q-1~deb9u1), so it will not be upgraded
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Would download/install/remove packages.
Is this normal behavior?
Phil
Last edited by pcalvert (2020-06-15 18:06:15)
Offline
are you missing -security repos perhaps? what does apt policy libssl1.0.2 say?
other than that, maybe network or mirror error, sync delay, other.. (?)
Offline
Thanks for the reply. Here's that info:
$ apt policy libssl1.0.2
libssl1.0.2:
Installed: 1.0.2q-1~deb9u1
Candidate: 1.0.2q-1~deb9u1
Version table:
1.0.2r-1~deb9u1 500
500 http://deb.devuan.org/merged ascii-security/main i386 Packages
*** 1.0.2q-1~deb9u1 990
990 http://deb.devuan.org/merged ascii/main i386 Packages
100 /var/lib/dpkg/status
That's an interesting (but puzzling) result.
Offline
check your /etc/apt/preferences.d/ files. i'd guess some apt pinning is to blame..
proceed with security upgrades first!
Offline
I am not using apt pinning. This directory is empty:
/etc/apt/preferences.d
However, I have this...
// Set ASCII as the default release
APT::Default-Release "ascii";
...in this directory:
/etc/apt/apt.conf.d
Could that be the reason?
Offline
Setting the default release changes the priority from 500 to 990 on the ascii main version. I just tested it - they were both 500 before I set the default.
I guess you'll need to add '-t ascii-security' to your install command.
Offline
The reason I set ASCII as the default release was because I am using an MX Linux repo for their adobe-flashplugin package.
Contents of /etc/apt/sources.list.d/mx-17.list:
# MX Community Main and Test Repos
deb http://mxrepo.com/mx/repo/ stretch non-free #main
#deb http://la.mxrepo.com/mx/testrepo/ stretch test
However, with the MX-17 repo enabled, APT tries to pull in other packages:
$ aptitude upgrade -s
The following packages will be upgraded:
intel-microcode unrar
2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,557 kB of archives. After unpacking 9,216 B will be used.
Note: Using 'Simulate' mode.
Do you want to continue? [Y/n/?]
If I lower the priority of the MX-17 repo to 400, will that solve this problem? If so, how do I do that?
Offline
/etc/apt/preferences.d/mxrepo (or some other file name)
Package: *
Pin: origin "mxrepo.com"
Pin-Priority: 400
I think that will work. The man page for apt_preferences says that origin can match a hostname. I don't know if you need to make a separate entry for la.mxrepo.com or if the one will get both.
Offline
What about openssh security update???
debian- https://security-tracker.debian.org/tracker/DSA-4387-2
stretch (security) 1:7.4p1-10+deb9u6
devuan in security apt policy still has
1:7.4p1-10+deb9u5
Offline
@fsmithred: That works. Thank-you!
@anonymous: Try running aptitude update or apt-get update and then check again.
Here are my results:
$ apt policy openssh-client
openssh-client:
Installed: 1:7.4p1-10+deb9u6
Candidate: 1:7.4p1-10+deb9u6
Version table:
*** 1:7.4p1-10+deb9u6 500
500 http://deb.devuan.org/merged ascii-security/main i386 Packages
100 /var/lib/dpkg/status
1:7.4p1-10+deb9u5 500
500 http://deb.devuan.org/merged ascii/main i386 Packages
Phil
Offline
/etc/apt/preferences.d/mxrepo (or some other file name)
Package: * Pin: origin "mxrepo.com" Pin-Priority: 400
I think that will work. The man page for apt_preferences says that origin can match a hostname. I don't know if you need to make a separate entry for la.mxrepo.com or if the one will get both.
It turned out that a pin priority of 400 is too high. Even 100 is too high. I lowered it to 50 and now it works; 99 probably would have also worked, but I didn't bother testing it since the problem was already solved.
EDIT:
I thought I had this working, but further testing (via routine usage of the system) proved me wrong. I believe I have it working now, though, using this configuration:
Package: adobe-flashplugin
Pin: origin "mxrepo.com"
Pin-Priority: 100
Package: *
Pin: origin "mxrepo.com"
Pin-Priority: 50
Phil
Last edited by pcalvert (2019-04-19 18:14:02)
Offline
Something must have changed recently. I have an ascii install that has ascii-backports, beowulf and ceres all pinned to 100, and yesterday I noticed that apt-cache policy was telling me that ceres had the Candidate version.
I just changed those pin priorities to 99 and checked again. Now backports has the candidate, and the backports priority shows as 100 even when I've got it set to 99 in my preferences.
It should be showing me the ascii version as the candidate.
Pin-Priority: 100 (on ascii-backports, beowulf and ceres)
user@ascii:~$ apt-cache policy debootstrap
debootstrap:
Installed: 1.0.89+devuan2
Candidate: 1.0.114+devuan1
Version table:
1.0.114+devuan1 100
100 http://deb.devuan.org/merged ceres/main amd64 Packages
1.0.110+devuan1 100
100 http://deb.devuan.org/merged beowulf/main amd64 Packages
1.0.110~bpo9+1 100
100 http://deb.devuan.org/merged ascii-backports/main amd64 Packages
*** 1.0.89+devuan2 100
100 /var/lib/dpkg/status
1.0.89-devuan2.1 500
500 http://pkgmaster.devuan.org/merged ascii/main amd64 Packages
Pin-Priority: 99 (on ascii-backports, beowulf and ceres)
user@ascii:~$ apt-cache policy debootstrap
debootstrap:
Installed: 1.0.89+devuan2
Candidate: 1.0.110~bpo9+1
Version table:
1.0.114+devuan1 99
99 http://deb.devuan.org/merged ceres/main amd64 Packages
1.0.110+devuan1 99
99 http://deb.devuan.org/merged beowulf/main amd64 Packages
1.0.110~bpo9+1 100
100 http://deb.devuan.org/merged ascii-backports/main amd64 Packages
*** 1.0.89+devuan2 100
100 /var/lib/dpkg/status
1.0.89-devuan2.1 500
500 http://pkgmaster.devuan.org/merged ascii/main amd64 Packages
Pin-Priority: 50 (on ascii-backports, beowulf and ceres)
user@ascii:~$ apt-cache policy debootstrap
debootstrap:
Installed: 1.0.89+devuan2
Candidate: 1.0.110~bpo9+1
Version table:
1.0.114+devuan1 50
50 http://deb.devuan.org/merged ceres/main amd64 Packages
1.0.110+devuan1 50
50 http://deb.devuan.org/merged beowulf/main amd64 Packages
1.0.110~bpo9+1 100
100 http://deb.devuan.org/merged ascii-backports/main amd64 Packages
*** 1.0.89+devuan2 100
100 /var/lib/dpkg/status
1.0.89-devuan2.1 500
500 http://pkgmaster.devuan.org/merged ascii/main amd64 Packages
Offline
Hi fsmithred,
nothing has changed in the repo: there was just a mistake in the numbering of the latest version of debootstrap in ascii. It should have been named +devuan2.1 while it has suffix -devuan2.1 (notice the difference between "-" and "+"), As such, version "-devuan2.1" is lower than any of the other versions, hence it is never considered for installation. Also, "~" sorts before anything else :-)
HTH
KatolaZ
Offline
dovecot
debian- https://security-tracker.debian.org/tra … -2019-3814
stretch (security) 1:2.2.27-3+deb9u4
devuan in security apt policy/apt-cache policy still has
1:2.2.27-3+deb9u3
hmmm
Offline
dovecot
debian- https://security-tracker.debian.org/tra … -2019-3814
stretch (security) 1:2.2.27-3+deb9u4devuan in security apt policy/apt-cache policy still has
1:2.2.27-3+deb9u3hmmm
Not anymore. You must have caught it right before the repo updated.
1:2.2.27-3+deb9u4 0
500 http://auto.mirror.devuan.org/merged/ ascii-security/main amd64 Packages
500 http://pkgmaster.devuan.org/merged/ ascii-security/main amd64 Packages
500 http://deb.devuan.org/merged/ ascii-security/main amd64 Packages
10 http://security.debian.org/ stretch/updates/main amd64 Packages
Offline
again repo delay?
debian - thunderbird
1:60.6.1-1~deb9u1
devuan - thunderbird
1:60.5.1-1~deb9u1
Offline
Here's another example:
- -------------------------------------------------------------------------
Debian Security Advisory DSA-4447-1 security@debian.org
https://www.debian.org/security/ Moritz Muehlenhoff
May 15, 2019 https://www.debian.org/security/faq
- -------------------------------------------------------------------------
Package : intel-microcode
CVE ID : CVE-2018-12126 CVE-2018-12127 CVE-2018-12130
CVE-2019-11091
This update ships updated CPU microcode for most types of Intel CPUs. It
provides mitigations for the MSBDS, MFBDS, MLPDS and MDSUM hardware
vulnerabilities.
To fully resolve these vulnerabilities it is also necessary to update
the Linux kernel packages as released in DSA 4444.
For the stable distribution (stretch), these problems have been fixed in
version 3.20190514.1~deb9u1.
We recommend that you upgrade your intel-microcode packages.
For the detailed security status of intel-microcode please refer to
its security tracker page at:
https://security-tracker.debian.org/tracker/intel-microcode
Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://www.debian.org/security/
More than 60 hours later and the update has not shown up yet:
$ apt policy intel-microcode
intel-microcode:
Installed: 3.20180807a.2~deb9u1
Candidate: 3.20180807a.2~deb9u1
Version table:
*** 3.20180807a.2~deb9u1 500
500 http://deb.devuan.org/merged ascii/non-free i386 Packages
100 /var/lib/dpkg/status
3.20180807a.1~deb9u1 500
500 http://deb.devuan.org/merged ascii-security/non-free i386 Packages
Phil
Offline
indeed, that's strange and an issue for ascii. it should have this version 3.20190514.1~deb9u1 from debian.
btw, beowulf got the update 3 days ago :
2019-05-15 upgrade intel-microcode:amd64 3.20190312.1 3.20190514.1
Offline
Here's some more data:
$ apt policy intel-microcode:amd64
intel-microcode:amd64:
Installed: (none)
Candidate: 3.20190514.1~deb9u1
Version table:
3.20190514.1~deb9u1 500
500 http://deb.devuan.org/merged ascii-security/non-free amd64 Packages
3.20180807a.2~deb9u1 500
500 http://deb.devuan.org/merged ascii/non-free amd64 Packages
$ apt policy intel-microcode
intel-microcode:
Installed: 3.20180807a.2~deb9u1
Candidate: 3.20180807a.2~deb9u1
Version table:
*** 3.20180807a.2~deb9u1 500
500 http://deb.devuan.org/merged ascii/non-free i386 Packages
100 /var/lib/dpkg/status
3.20180807a.1~deb9u1 500
500 http://deb.devuan.org/merged ascii-security/non-free i386 Packages
So, the package for 64-bit systems is up to date, but the one for 32-bit systems is not. Although I am by no means an expert on Devuan, this seems to suggest that Amprolla is not working properly.
Phil
Last edited by pcalvert (2019-05-18 21:21:09)
Offline
again repo delay?
debian stretch (64bit)- thunderbird
1:60.7.1-1~deb9u1
devuan ascii (64bit) - thunderbird
1:60.7.0-1~deb9u1
apt-cache policy thunderbird
---
https://security-tracker.debian.org/tra … hunderbird
Offline
Here's my result:
$ date && apt policy thunderbird
Sun Jun 16 12:56:56 EDT 2019
thunderbird:
Installed: 1:60.7.0-1~deb9u1
Candidate: 1:60.7.0-1~deb9u1
Version table:
2:52.9.1-2~mx17+2 50
50 http://mxrepo.com/mx/repo stretch/main i386 Packages
*** 1:60.7.0-1~deb9u1 500
500 http://deb.devuan.org/merged ascii-security/main i386 Packages
100 /var/lib/dpkg/status
1:60.6.1-1~deb9u1 500
500 http://deb.devuan.org/merged ascii/main i386 Packages
Offline
And here's mine:
$ apt-cache policy thunderbird
thunderbird:
Installed: (none)
Candidate: 1:60.7.1-1~deb9u1
Version table:
1:60.7.1-1~deb9u1 500
500 http://auto.mirror.devuan.org/merged ascii-security/main amd64 Packages
1:60.7.0-1~deb9u1 500
500 http://pkgmaster.devuan.org/merged ascii-security/main amd64 Packages
It's now on the urgent tasks list (again). Thanks for reporting.
Offline
Fixed.
thunderbird:
Installed: (none)
Candidate: 1:60.7.1-1~deb9u1
Version table:
1:60.7.1-1~deb9u1 500
500 http://pkgmaster.devuan.org/merged ascii-security/main amd64 Packages
500 http://auto.mirror.devuan.org/merged ascii-security/main amd64 Packages
Offline
I'm sorry, but i want to ask. Why do such delays happen?
What economists call over-production is but a production that is above the purchasing power of the worker, who is reduced to poverty by capital and state.
----+- Peter Kropotkin -+----
Offline
I'm sorry, but i want to ask. Why do such delays happen?
Here's the explanation that was posted on devuan-dev mailing list yesterday. (The script failed if there was a read timeout.)
Picked this up today. The issue was an unhandled exception in net.py.
I've pushed a fix to Gitlab[0] and applied this in production for both
pkgmaster.do and packages.do.[0] https://git.devuan.org/devuan-infrastru … a8252eb85f
The amprolla logs[1] are there for a reason
Just grep it for 'ERR' to see what's wrong.
Edit: Phil, I changed the subject line in your original post to 'Solved'. If that's wrong, please let me know. (squeeky wheel law)
Offline