... so, apparently, people are determined to actually fall for this clown. I was initially going to send this off-list, but I'd just like to shut down these claims fast before people start falling for it. We already had two people fall for it, people whose opinions I am not generally inclined to disrespect. Let's make this clear: None of these claims are true! At all! Not even one of them! On 07/02/2017 04:39 PM, NicoHood wrote: > I've checked the links and while those suggestions are a bit harsh, they > are still valid: You have grabbed the troll bait! Please don't do that. Also, you're wrong. > * 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. Calling out specific package *maintainers* for a public shaming is always unacceptable, and picking on specific packages for the sake of something that only makes sense in the context of a *distro-wide* policy makes NO SENSE. Lots of things can use stronger hashes, in theory. We have ridden this hobby-horse all over arch-general, repeatedly, as you should know due to having contributed no small part of that conversation yourself. I am sick and tired of hearing you and others reignite that debate every time someone mentions the word "checksums", you aren't contributing any useful discussion about policy anymore. Posting about these packages and attempting to shame their maintainers on the mailing list is unacceptable, in the way posting to the mailing list about the chemical composition of peanut butter is unacceptable. > * 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. Stop being ludicrous. No one believes that you need two different hashes, sha256 is completely acceptable, end of story, and quite frankly, we use GPG signatures there so CRC checksums are all we need (and sha256 is way overkill but we have them anyway, so congrats). Are you genuinely trying to tell me you think there is something you haven't already said last time, which you think is useful to say regarding a potential *distro policy* ? > * 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 That PKGBUILD is ugly in the extreme due to containing junk variables that do not exist in any sense of pacman's source build systems, but it also only contains md5sums. Valid md5sums. Stop spreading FUD. This package therefore falls under the category of "attempted public shaming of packages using md5sums", and also "attempted public shaming of a specific *person* for making a stupid typo". This is not a valid point, this is exclusively rudeness with the explicit attempt to be rude. And you've fallen for it, hook, line, and sinker. > 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. systemd is validated with GPG, it doesn't matter whether the download transport is checked against the cacert system. GPG already ensures that this package cannot sneakily use a source that isn't signed with the validpgpkeys. > 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. Because he has been banned from the forums, from IRC, from the bugtracker, and from the mailing list due to extreme rudeness that makes him intolerable to talk to, and also because he is wrong or a liar, more often than he is right. And because you just fell for him, as many well-meaning people who aren't familiar with him do. -- Eli Schwartz
Attachment:
signature.asc
Description: OpenPGP digital signature
