SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
OK, I will install Slackware64-current in a VM to check the differences in layout vs 14.2.
As an aside, I am a bit puzzled that /isolinux/initrd still includes glibc-2.28 in Slackware-current (dated 01-Feb-2019 01:24 on https://mirrors.slackware.com/slackw...rent/isolinux/). It has probably been rebuilt before the upgrade of glibc, dated 01-Feb-2019 05:09. Maybe this doesn't matter.
Last edited by Didier Spaier; 02-05-2019 at 04:31 AM.
* CVE-2019-3814: If imap/pop3/managesieve/submission client has
trusted certificate with missing username field
(ssl_cert_username_field), under some configurations Dovecot
mistakenly trusts the username provided via authentication instead
of failing.
* ssl_cert_username_field setting was ignored with external SMTP AUTH,
because none of the MTAs (Postfix, Exim) currently send the
cert_username field. This may have allowed users with trusted
certificate to specify any username in the authentication. This bug
didn't affect Dovecot's Submission service.
The double free patch for mysql-driver is not included in this release so the SlackBuild still needs to patch it.
Distribution: Slackware on server, Bunsenlabs on desktop
Posts: 32
Rep:
Since Slackware current has just been upgraded to glibc-2.29 on 01-FEB-2019, the new Slackware 15.0 release does not seem to appear anytime soon. Historically a release appears many months after a glibc upgrade:
14.0:
26-MAR-2012: upgrade to glibc-2.15
26-SEP-2012: release with glibc-2.15
14.1:
12-MAR-2013: upgrade to glibc-2.17
04-NOV-2013: release with glibc-2.17
14.2:
23-FEB-2016: upgrade to glibc-2.23
30-JUN-2016: release with glibc-2.23
OK, I will install Slackware64-current in a VM to check the differences in layout vs 14.2.
As an aside, I am a bit puzzled that /isolinux/initrd still includes glibc-2.28 in Slackware-current (dated 01-Feb-2019 01:24 on https://mirrors.slackware.com/slackw...rent/isolinux/). It has probably been rebuilt before the upgrade of glibc, dated 01-Feb-2019 05:09. Maybe this doesn't matter.
Well, eventually instead of basing the new Slint installer on the initrd of Slackware64-current, I will just base it as before on the initrd of Slackware64-14.2, but replacing the kernel modules in it by those shipped in Slackware64-current (version 4.19.19 at time of writing). This is easy to do with the script build_installer.sh in slackware64-current/source/installer/ (and that works, I just checked in a VM).
Congrats and huge thanks to Stuart, Eric and Patrick for sharing it and the other stuff to (re)build the installer!
And... Sorry for the noise.
Last edited by Didier Spaier; 02-05-2019 at 12:48 PM.
Do most people not trust their CPU to initialize the RNG? Looking at Fedora, I see they've also gone with =y one this one.
If you don't trust your CPU, you can always boot with random.trust_cpu=off - the CONFIG option only sets a default value.
It's the changing of the kernel default that's surprising, away from the sceptical default. Is trust not something that is for users to actively to choose to delegate?
Since Slackware current has just been upgraded to glibc-2.29 on 01-FEB-2019, the new Slackware 15.0 release does not seem to appear anytime soon. Historically a release appears many months after a glibc upgrade:
Welcome to LQ.
Historically, glibc updates were a lot more disruptive than they've been in recent years, and with nobodino's help verifying that the new glibc didn't adversely affect the ability to compile *any* of the Slackware packages from source, I wouldn't expect this glibc update to affect the release schedule (heh) at all.
Historically, glibc updates were a lot more disruptive than they've been in recent years, and with nobodino's help verifying that the new glibc didn't adversely affect the ability to compile *any* of the Slackware packages from source, I wouldn't expect this glibc update to affect the release schedule (heh) at all.
Release schedule? I can tell you when slackware 15.0 will be released, within 2 days of the first working day after Easter 2019.
How do I have such good ESP? Because on Easter Sunday we are upgrading all our remaining 13/14's to 14.2
i get this interesting info , after check python modules status with pip.
Quote:
pip list --outdated
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.
Do most people not trust their CPU to initialize the RNG? Looking at Fedora, I see they've also gone with =y one this one.
If you don't trust your CPU, you can always boot with random.trust_cpu=off - the CONFIG option only sets a default value.
On a related note - all kernels which contain the fix for CVE-2018-1108 no longer make the RNG "fully" initialized after seeding it by writing some randomness (saved from previous boot) into /dev/[u]random. If there are no other sources of entropy which bump entropy counter (be it "trust cpu manufacturer", "use virtio-rng", "make disks do some seeks", "receive network traffic" or "smash on keyboard like a mad person"), even reading from /dev/urandom will block - including getrandom(2) system call (even when called with GRND_NONBLOCK).
That means on such systems what Slackware does in rc.S:
Code:
if [ -r /proc/sys/kernel/random/poolsize ]; then
dd if=/dev/urandom of=/etc/random-seed count=1 bs=$(expr $(cat /proc/sys/kernel/random/poolsize) / 8) 2> /dev/null
else
dd if=/dev/urandom of=/etc/random-seed count=1 bs=512 2> /dev/null
fi
is no longer "fully" effective.
If you trust that seed to be truly random, it should be safe to open /dev/random and use ioctl RNDADDTOENTCNT bump the entropy count high enough to make crng "fully" initialized. If you're looking for source to back this statement up (I'm no cryptographer, so I spent some time wondering about it myself), see https://twitter.com/tehjh/status/993315177545261060
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
