On 07/02/2017 10:18 PM, Eli Schwartz via arch-general wrote: > On 07/02/2017 04:12 PM, User via arch-general wrote: >> Sébastien Luttringer, https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/btrfs-progs&id=959539e1f7df15986f336bb03225ea796a44ca3e , https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/sha256sums.asc, https://lists.archlinux.org/pipermail/arch-general/2016-December/042700.html . >> Tobias Powalowski, https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/hdparm&id=2bd43d6fec063156c40dfc0d5ba115155b09cfc1 , i waited and no one said anything all this time. you do not help each other. > > So basically, you are confirming you are fnodeuser? > > I guess you thought this was a good way to get around being blacklisted > from the mailing list due to continuous rudeness and spammy behaviour. > I've checked the links and while those suggestions are a bit harsh, they are still valid: * btrfs-progs can use stronger hashes. This always makes sense and can be changed within seconds. Especially because upstream hashes are available for comparison beside the Signature. * The suggestion to add sha2 hashes for the .iso download is valid. There is no good reason why to not also add another (more secure) algorithm, no matter if the current solution might be okay today, but maybe not in the future. * The last link shows a real issue of the PKGBUILD. The sha512 values are wrong and on top of that the variable name is misspelled (double ss). This should be fixed and only contains sha512sums or both No matter who he is, he is right. Also with his previous email, we should build systemd with https sources. If we ever have malicious software in our Distribution we will get lots of trouble. And we dont want this to happen just because we did not apply such an obvious fix. So why are we so resistant against those suggestions? Those are good and valid, no matter who this guy is and how he interacts with people. From the technical point of view he is right. And we all should care for our users, because we are responsible for them. ~Nico
Attachment:
signature.asc
Description: OpenPGP digital signature
