mirror of
git://slackware.nl/current.git
synced 2025-01-29 08:36:40 +01:00
d66220bda5
a/kernel-generic-5.14.8-x86_64-1.txz: Upgraded.
a/kernel-huge-5.14.8-x86_64-1.txz: Upgraded.
a/kernel-modules-5.14.8-x86_64-1.txz: Upgraded.
ap/itstool-2.0.7-x86_64-1.txz: Upgraded.
d/kernel-headers-5.14.8-x86-1.txz: Upgraded.
k/kernel-source-5.14.8-noarch-1.txz: Upgraded.
l/libmtp-1.1.19-x86_64-1.txz: Upgraded.
n/getmail-6.18.4-x86_64-1.txz: Upgraded.
n/openssh-8.8p1-x86_64-1.txz: Upgraded.
Please note "Potentially-incompatible changes" from the release notes:
This release disables RSA signatures using the SHA-1 hash algorithm
by default. This change has been made as the SHA-1 hash algorithm is
cryptographically broken, and it is possible to create chosen-prefix
hash collisions for <USD$50K [1]
For most users, this change should be invisible and there is
no need to replace ssh-rsa keys. OpenSSH has supported RFC8332
RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys
will automatically use the stronger algorithm where possible.
Incompatibility is more likely when connecting to older SSH
implementations that have not been upgraded or have not closely tracked
improvements in the SSH protocol. For these cases, it may be necessary
to selectively re-enable RSA/SHA1 to allow connection and/or user
authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms
options. For example, the following stanza in ~/.ssh/config will enable
RSA/SHA1 for host and user authentication for a single destination host:
Host old-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
We recommend enabling RSA/SHA1 only as a stopgap measure until legacy
implementations can be upgraded or reconfigured with another key type
(such as ECDSA or Ed25519).
[1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and
Application to the PGP Web of Trust" Leurent, G and Peyrin, T
(2020) https://eprint.iacr.org/2020/014.pdf
isolinux/initrd.img: Rebuilt.
kernels/*: Upgraded.
usb-and-pxe-installers/usbboot.img: Rebuilt.
|
||
|---|---|---|
| .. | ||
| a | ||
| ap | ||
| d | ||
| e | ||
| f | ||
| installer | ||
| k | ||
| kde | ||
| l | ||
| n | ||
| t | ||
| tcl | ||
| x | ||
| xap | ||
| xfce | ||
| y | ||
| buildlist-from-changelog.sh | ||
| make_world.sh | ||
| README.TXT | ||
This is the source used for Slackware. To look for a particular bit of source (let's say for 'cp'), first you would look for the full path: fuzzy:~# which cp /bin/cp Then, you grep for the package it came from. Note that the leading '/' is removed: fuzzy:~# grep bin/cp /var/log/packages/* /var/log/packages/cpio-2.4.2.91-i386-1:bin/cpio /var/log/packages/fileutils-4.1-i386-2:bin/cp /var/log/packages/gcc-2.95.3-i386-2:usr/bin/cpp /var/log/packages/gnome-applets-1.4.0.5-i386-1:usr/bin/cpumemusage_applet From this, you can see that 'cp' came from the fileutils-4.1-i386-2 package. The source will be found in a corresponding subdirectory. In this case, that would be ./a/bin. Don't be fooled into thinking that the _bin.tar.gz in this directory is the package with the source code -- anything starting with '_' is just a framework package full of empty files with the correct permissions and ownerships for the completed package to use. Many of these packages now have scripts that untar, patch, and compile the source automatically. These are the 'SlackBuild' scripts. Moving back to the example above, you can figure out which package the bin/cp source came from by examining the SlackBuild script. Have fun! --- Patrick J. Volkerding volkerdi@slackware.com