LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 09-09-2020, 01:46 PM   #5536
saxa
Senior Member
 
Registered: Aug 2004
Location: Nova Gorica, Salvador
Distribution: Slackware
Posts: 1,213

Rep: Reputation: 297Reputation: 297Reputation: 297

Would be nice to have a unique checksum of the clean system or the latest released software as a full install.
 
Old 09-09-2020, 02:04 PM   #5537
elcore
Senior Member
 
Registered: Sep 2014
Distribution: Slackware
Posts: 1,753

Rep: Reputation: Disabled
Quote:
Originally Posted by saxa View Post
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.
 
Old 09-09-2020, 02:28 PM   #5538
karlmag
Member
 
Registered: Apr 2014
Distribution: Slackware
Posts: 127

Rep: Reputation: Disabled
Quote:
Originally Posted by saxa View Post
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 View Post
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).

Thanks
--
KarlMag
 
Old 09-09-2020, 03:38 PM   #5539
alex14641
Member
 
Registered: Feb 2016
Distribution: Slackware64_14.2, Slackware 15.0, Slackware64_current
Posts: 322

Rep: Reputation: Disabled
bluez patch no longer needed

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.
 
Old 09-10-2020, 05:58 AM   #5540
saxa
Senior Member
 
Registered: Aug 2004
Location: Nova Gorica, Salvador
Distribution: Slackware
Posts: 1,213

Rep: Reputation: 297Reputation: 297Reputation: 297
Here we go, I hope we can get all the new glib/gtk stuff in, releasing in these days:

glib-2.66.0
https://download.gnome.org/sources/g...-2.66.0.tar.xz

I believe it will be a straight forward upgrade.
 
Old 09-10-2020, 03:56 PM   #5541
saxa
Senior Member
 
Registered: Aug 2004
Location: Nova Gorica, Salvador
Distribution: Slackware
Posts: 1,213

Rep: Reputation: 297Reputation: 297Reputation: 297
vala-0.50.0
https://download.gnome.org/sources/v...-0.50.0.tar.xz
 
Old 09-10-2020, 04:40 PM   #5542
saxa
Senior Member
 
Registered: Aug 2004
Location: Nova Gorica, Salvador
Distribution: Slackware
Posts: 1,213

Rep: Reputation: 297Reputation: 297Reputation: 297
librsvg-2.50.0
https://download.gnome.org/sources/l...-2.50.0.tar.xz
 
Old 09-10-2020, 04:40 PM   #5543
titopoquito
Senior Member
 
Registered: Jul 2004
Location: Lower Rhine region, Germany
Distribution: Slackware64 14.2 and current, SlackwareARM current
Posts: 1,646

Rep: Reputation: 146Reputation: 146
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
 
4 members found this post helpful.
Old 09-10-2020, 05:10 PM   #5544
drgibbon
Senior Member
 
Registered: Nov 2014
Distribution: Slackware64 15.0
Posts: 1,221

Rep: Reputation: 943Reputation: 943Reputation: 943Reputation: 943Reputation: 943Reputation: 943Reputation: 943Reputation: 943
Quote:
Originally Posted by elcore View Post
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).
 
Old 09-11-2020, 06:31 AM   #5545
GazL
LQ Veteran
 
Registered: May 2008
Posts: 6,897

Rep: Reputation: 5019Reputation: 5019Reputation: 5019Reputation: 5019Reputation: 5019Reputation: 5019Reputation: 5019Reputation: 5019Reputation: 5019Reputation: 5019Reputation: 5019
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.

I find 'signify' interesting, but the disruption involved with swapping to it wouldn't be worth the minimal advantages¹ it has over gpg.


---
¹ which basically boil down to it being a more focussed tool than gpg. i.e. "Do one thing and do it well".
 
Old 09-11-2020, 07:19 AM   #5546
saxa
Senior Member
 
Registered: Aug 2004
Location: Nova Gorica, Salvador
Distribution: Slackware
Posts: 1,213

Rep: Reputation: 297Reputation: 297Reputation: 297
gvfs-1.46.0
https://download.gnome.org/sources/gvfs/1.46/c.tar.xz
 
Old 09-11-2020, 08:44 AM   #5547
elcore
Senior Member
 
Registered: Sep 2014
Distribution: Slackware
Posts: 1,753

Rep: Reputation: Disabled
Quote:
Originally Posted by GazL View Post
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.
 
1 members found this post helpful.
Old 09-11-2020, 10:51 AM   #5548
GazL
LQ Veteran
 
Registered: May 2008
Posts: 6,897

Rep: Reputation: 5019Reputation: 5019Reputation: 5019Reputation: 5019Reputation: 5019Reputation: 5019Reputation: 5019Reputation: 5019Reputation: 5019Reputation: 5019Reputation: 5019
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.

Last edited by GazL; 09-11-2020 at 10:53 AM.
 
3 members found this post helpful.
Old 09-11-2020, 12:35 PM   #5549
saxa
Senior Member
 
Registered: Aug 2004
Location: Nova Gorica, Salvador
Distribution: Slackware
Posts: 1,213

Rep: Reputation: 297Reputation: 297Reputation: 297
json-glib-1.6.0
https://download.gnome.org/sources/j...b-1.6.0.tar.xz
 
Old 09-11-2020, 01:49 PM   #5550
drgibbon
Senior Member
 
Registered: Nov 2014
Distribution: Slackware64 15.0
Posts: 1,221

Rep: Reputation: 943Reputation: 943Reputation: 943Reputation: 943Reputation: 943Reputation: 943Reputation: 943Reputation: 943
Quote:
Originally Posted by GazL View Post
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 View Post
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.

Last edited by drgibbon; 09-11-2020 at 05:58 PM.
 
2 members found this post helpful.
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Requests for -current (20151216) rworkman Slackware 3441 12-28-2017 03:50 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 10:07 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration