Desired updates to -current (20150422)

ReaperX7 · 07-30-2015, 03:03 AM

That might be a concern as honestly the RNG being at a predictable state could be a security issue with keys. By randomizing the RNG at primary boot, you remove any possibility of the RNG being possibly, even remotely, used to predict the security keys for ssh.

Good find ttk. I wonder if other distributions do similar?

ttk · 07-30-2015, 10:22 AM

Quote:

Originally Posted by ReaperX7

I wonder if other distributions do similar?

RHEL and its derivatives do it, at least:

Code:

# find /etc/rc.d/* -type f -exec grep -H random-seed {} \;
/etc/rc.d/rc.sysinit:if [ -f "/var/lib/random-seed" ]; then
/etc/rc.d/rc.sysinit:        cat /var/lib/random-seed > /dev/urandom
/etc/rc.d/rc.sysinit:        [ "$READONLY" != "yes" ] && touch /var/lib/random-seed
/etc/rc.d/rc.sysinit:        chmod 600 /var/lib/random-seed
/etc/rc.d/rc.sysinit:        dd if=/dev/urandom of=/var/lib/random-seed count=1 bs=4096 2>/dev/null
/etc/rc.d/init.d/halt:touch /var/lib/random-seed
/etc/rc.d/init.d/halt:chmod 600 /var/lib/random-seed
/etc/rc.d/init.d/halt:action $"Saving random seed: " dd if=/dev/urandom of=/var/lib/random-seed count=1 bs=512 2>/dev/null

55020 · 07-30-2015, 10:27 AM

But (unless I'm missing the point) rc.S runs on every boot. It's S for System Initialisation, not S for Single User. If you copy the code into rc.M, the code will be run twice.

ttk · 07-30-2015, 12:00 PM

Quote:

Originally Posted by 55020

But (unless I'm missing the point) rc.S runs on every boot. It's S for System Initialisation, not S for Single User. If you copy the code into rc.M, the code will be run twice.

Thank you, 55020. I didn't realize that. Thought S was "single user".

I withdraw my request :-)

ReaperX7 · 07-31-2015, 04:00 AM

It's kinda both. S starts up everything before M starts and initializes runlevel 2~5. S still loads single user via K.

ttk · 07-31-2015, 10:05 AM

The ultimate point is that I can pre-populate my new install's /etc/random-seed after running setup but before first boot, and rc.S will mix the provided entropy into /dev/urandom before rc.sshd generates system ssh keys.

I'm writing up some scripts that do things like this now -- patch configuration files and rc scripts, inject entropy, install random scripts not worth packaging, etc. Basically all the little tasks which are hard to remember to do before first boot and/or a pain to do manually in the minimal busybox environment.

ReaperX7 · 07-31-2015, 11:32 PM

If it improves security, even a bit by making the keys more randomized to prevent ssh security problems, then +1. Plus, it's a small unintrusive edit. Nice job ttk.

moesasji · 08-14-2015, 03:57 PM

Seeing the problems Networkmanager appears to cause it would be good if Wicd in extra gets updated to the latest stable release, which is 1.7.3. See https://launchpad.net/wicd/+download.

hitest · 08-14-2015, 04:08 PM

Quote:

Originally Posted by moesasji

Seeing the problems Networkmanager appears to cause it would be good if Wicd in extra gets updated to the latest stable release, which is 1.7.3. See https://launchpad.net/wicd/+download.

I'm running Slackware on two laptops, and three desktops. One installation of 14.1, one install of Slackware-current, and three Slackware64-current installs. All units use Networkmanager. All units are functioning well with no issues to report.

moesasji · 08-14-2015, 04:15 PM

Quote:

Originally Posted by hitest

All units are functioning well with no issues to report.

Seems very hit and miss. One of my laptops suddenly refuses to connect to a WPA2 encrypted network, while working fine on other networks. If you look in the forum I'm not the only one as upstream doesn't test with dhcpd.

Anyway the comment was primarily that after 2.5 year there is an update to Wicd which is included in /extra, so worth updating.

volkerdi · 08-14-2015, 04:22 PM

Quote:

Originally Posted by moesasji

Seeing the problems Networkmanager appears to cause it would be good if Wicd in extra gets updated to the latest stable release, which is 1.7.3. See https://launchpad.net/wicd/+download.

I'm thinking it would be better to just throw that one away at this point.

aaazen · 08-14-2015, 04:32 PM

Quote:

Originally Posted by comet.berkeley

Dosfstools 3.0.28 is out in the Git repository.

https://github.com/dosfstools/dosfstools/releases

Older version 3.0.27 is a pure bug fix release that fixed a bug I found on a dos file system during fsck.fat:

Code:

...
Bad short file name ().
Auto-renaming it.
Renamed to
...

Okay so there is some progress in current, we are now up to version 3.0.26 of dosfstools

If we are not going to version 3.0.27 nor 3.0.28, can we at least have the following patch applied from version 3.0.27?

https://github.com/dosfstools/dosfst...18f4820ea08e77

Here is a copy of the patch:

Code:

--- src/check.c.orig    2014-03-07 09:35:11.000000000 -0800
+++ src/check.c 2015-08-14 14:08:56.499652136 -0700
@@ -959,9 +959,9 @@
        fs_read(offset, sizeof(DIR_ENT), &de);
     else {
        /* Construct a DIR_ENT for the root directory */
+       memset(&de, 0, sizeof de);
        memcpy(de.name, "           ", MSDOS_NAME);
        de.attr = ATTR_DIR;
-       de.size = de.time = de.date = 0;
        de.start = htole16(fs->root_cluster & 0xffff);
        de.starthi = htole16((fs->root_cluster >> 16) & 0xffff);
     }

ReaperX7 · 08-15-2015, 09:35 AM

Quote:

Originally Posted by volkerdi

I'm thinking it would be better to just throw that one away at this point.

What was the issue that was plaguing the newer Wicd release?

chrisretusn · 08-17-2015, 05:23 AM

LibRaw has been updated to LibRaw 0.17, exiv2 has been updated to Exiv2 0.25

http://www.exiv2.org/changelog.html

http://www.libraw.org/download#stable

gmgf · 08-17-2015, 11:13 AM

nettle-3.1.1 is available since 24/04/2015