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.
Would be nice to have a unique checksum of the clean system or the latest released software as a full install.
Not sure what you mean, but this is not possible unless you mean to re-check every single file in clean -current install, every time it is patched.
One could tar the entire system and check the archive, if that helps. I do this for all backups.
Would be nice to have a unique checksum of the clean system or the latest released software as a full install.
Quote:
Originally Posted by elcore
Not sure what you mean, but this is not possible unless you mean to re-check every single file in clean -current install, every time it is patched.
One could tar the entire system and check the archive, if that helps. I do this for all backups.
I guess depending on *why* you want to do this, the first thing that comes to mind is to have a local repository and checksum every package before installing.
But the use case might be somewhat different.
Next would e.g be to install packages to a separate directory, checksum the files and then compare those with what you have on your live system.
Both of those more or less requires having a local repository though - and some disk space to spare for the checksumming. And also some CPU cycles to spare for the checksumming (it's not that demanding though).
refresh_adv_manager_for_non-LE_devices.diff.gz no longer needs to be applied to the bluez source code: btd_adv_manager_refresh in advertising.c now has a null pointer check to prevent the crash from occurring. I've been running bluez 5.55 since it first came out with no LE devices and no crashes.
Distribution: Slackware64 14.2 and current, SlackwareARM current
Posts: 1,646
Rep:
Enhance installer
I would like to suggest to enhance the installer. In my case the installer was not able to find the appropriate EFI partition, which would have resulted in an unbootable system.
My thoughts after trying to understand what the installer does regarding automatically matching an EFI partition:
The script only matches the first 8 chars, so it can reliably detect block devices like /dev/sda but not /dev/mapper or /dev/nvme0n1p1
That means it cannot match the correct EFI partition if the root partition is on LVM, LUKS or on a newer NVME hard disk with longer naming scheme.
To solve that, I fiddled with the installer script (SeTEFI),
adding stuff to detect the underlying physical device (taken from mkinitrd-command-generator.sh, so the code is known to Patrick and well tested) and
check if the root partition is on a NVME device and adjust the matching command to 12 chars instead of just 8.
I guess it won't get included exactly like that anyway, but maybe it helps somehow in getting the change applied to the installer for Slackware 15.
Unfortunately I cannot test it on a real machine just now, or else my wife will probably kill me if I bork my new laptop. But I took some time to understand which format SeTplist for example has and tested the snippet with a fake SeTplist and SeTefipartitions.
Code:
--- installer-current-old/usr/lib/setup/SeTEFI 2019-12-30 21:05:21.000000000 +0100
+++ installer-proposed/usr/lib/setup/SeTEFI 2020-09-10 23:03:07.552636328 +0200
@@ -35,11 +35,94 @@
# will probably be on /dev/sda:
PREFERRED_EFI_PARTITION="$(cat $TMP/SeTefipartitions | head -n 1)"
+# the next part taken from /usr/share/mkinitrd/mkinitrd-command-generator.sh
+# Original copyright and license:
+# $Id: mkinitrd_command_generator.sh,v 1.45 2011/02/17 09:27:05 eha Exp eha $
+# Copyright 2013 Patrick J. Volkerding, Sebeka, Minnesota, USA
+# Copyright 2008, 2009, 2010, 2011 Eric Hameleers, Eindhoven, Netherlands
+# Contact: <alien@slackware.com>
+# Copyright 2008, 2009 PiterPUNK, Sao Paulo, SP, Brazil
+# Contact: <piterpunk@slackware.com>
+# All rights reserved.
+#
+# Permission to use, copy, modify, and distribute this software for
+# any purpose with or without fee is hereby granted, provided that
+# the above copyright notice and this permission notice appear in all
+# copies.
+#
+# THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
+# WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+# IN NO EVENT SHALL THE AUTHORS AND COPYRIGHT HOLDERS AND THEIR
+# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+# USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+# ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+# OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+# OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+
+if $( lvdisplay -c $ROOTDEV 1>/dev/null 2>/dev/null ); then
+ # Our root partition is on a LV:
+ # Search the Physical Volume of our Logical Volume:
+ MYVG=$( echo $(lvdisplay -c $ROOTDEV 2>/dev/null) | cut -d: -f2 )
+ for LINE in $(pvdisplay -c) ; do
+ VG=$(echo $LINE | cut -d: -f2)
+ [ "$VG" = "$MYVG" ] && break
+ done
+ PV=$(echo $LINE | cut -d: -f1)
+ # Check if there is a LUKS device underneath:
+ if $( cryptsetup status $PV 1>/dev/null 2>/dev/null ) ; then
+ # Our root partition's LV is on a LUKS volume:
+ REALDEV=$( cryptsetup status $PV | grep 'device: ' | tr -d ' ' | cut -d: -f2 )
+ BASEDEV=$REALDEV
+ else
+ BASEDEV=$PV
+ fi
+elif $( cryptsetup status $ROOTDEV 1>/dev/null 2>/dev/null ) ; then
+ # Our root device is on a LUKS volume:
+ REALDEV=$( cryptsetup status $ROOTDEV | grep 'device: ' | tr -d ' ' | cut -d: -f2 )
+ ROOTDEV=$(basename $ROOTDEV)
+ # Check for LVM:
+ for LV in $(lvdisplay -c 2>/dev/null | tr -d ' ' | cut -f1 -d:) ; do
+ # Note: cryptsetup shows the real device, whereas
+ # lvdisplay requires the /dev/<myvg>/... symlink to the real device.
+ if [ "$(readlink $LV)" = "$REALDEV" ]; then
+ REALDEV=$LV
+ break
+ fi
+ done
+ if $( lvdisplay -c $REALDEV 1>/dev/null 2>/dev/null ); then
+ # Our root partition's LUKS device is on a LV:
+ # Search the Physical Volume of our Logical Volume:
+ MYVG=$( echo $(lvdisplay -c $REALDEV 2>/dev/null) | cut -d: -f2 )
+ for LINE in $(pvdisplay -c) ; do
+ VG=$(echo $LINE | cut -d: -f2)
+ [ "$VG" = "$MYVG" ] && break
+ done
+ PV=$(echo $LINE | cut -d: -f1)
+ BASEDEV=$PV
+ else
+ BASEDEV=$REALDEV
+ fi
+else
+ BASEDEV=$ROOTDEV
+fi
+
+# On traditional SATA and IDE drives take the first 8 chars, to catch
+# newer NVME drives take 12 chars
+if test $(echo $BASEDEV | grep nvme); then
+ MAXCOMPARE=12
+else
+ MAXCOMPARE=8
+fi
+
# But we will also test to see if there is an EFI partition on the same
# device as the root partition, and if so, prefer that:
if [ -r $TMP/SeTrootdev ]; then
- if grep -q "$(cat $TMP/SeTrootdev | cut -b 1-8)" $TMP/SeTefipartitions ; then
- PREFERRED_EFI_PARTITION="$(grep "$(cat $TMP/SeTrootdev | cut -b 1-8)" $TMP/SeTefipartitions | head -n 1)"
+ if grep -q "$(echo $BASEDEV | cut -b 1-$MAXCOMPARE)" $TMP/SeTefipartitions ; then
+ PREFERRED_EFI_PARTITION="$(grep "$(echo $BASEDEV | cut -b 1-$MAXCOMPARE)" $TMP/SeTefipartitions | head -n 1)"
fi
fi
Had this idea the other day about doing sha512sum instead of md5sum for packaging/installation check.
Not going to argue which is better, just asking if that's something worth considering.
My understanding is that while this isn't an absolutely critical issue (i.e., MD5 is still preimage resistant), there's no good reason not to beef up the hash function to something stronger. Basically, why surf closer to the edge when a wider safety margin is available (and is computationally cheap).
I'm confused. What specifically are you talking about here with regard to the use of the hashes?
I'm confused too with some of the wording but 'unique checksum of the clean system' sounds like a way to check if the local build system is exact the same as the one upstream.
And that's something saxa has asked for, so a different question.
All I asked for was advice for, or against using sha512sum instead of md5sum when using packaging software which depends on md5sum to work.
When the repository only provides md5 I will use md5sum, but for another repository that provides sha512 I'm considering patching the software to use sha512sum.
If the Slackware repository provided sha512 I could drop md5 from this packaging software.
Ahh, I see, well I don't see how a CHECKSUMS.sha512 in addition to a CHECKSUMS.md5 would hurt anything, and it might ease the minds of those for whom the possibility of md5 collisions raises concerns. So, seems like a reasonable suggestion.
I'm confused. What specifically are you talking about here with regard to the use of the hashes?
IMO, the gpg signature files Pat already provides are the best bet for ensuring things haven't been tampered with.
Yeah that's true for normal use, all the binary packages are signed and the MD5s are only for checking download integrity. But say you're using source/SlackBuilds from a mirror, then you have to rely on the signed MD5s (apart from upstream sigs for external sources). If MD5 preimage attacks were possible (and as far as I can tell, they're not at the moment, but then again I wouldn't really know), someone could feasibly change a SlackBuild on a mirror and still have it match the signed MD5.
Quote:
Originally Posted by GazL
Ahh, I see, well I don't see how a CHECKSUMS.sha512 in addition to a CHECKSUMS.md5 would hurt anything, and it might ease the minds of those for whom the possibility of md5 collisions raises concerns. So, seems like a reasonable suggestion.
I agree that a stronger list of hashes alongside MD5s is a good idea. My understanding though is that a collision is where the target hash is free to vary (so this kind of thing), but in the case where the target hash is pre-specified (e.g., the ones that Pat signed), you need a preimage attack.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.