Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
On 3 July 2017 at 01:22, Eli Schwartz via arch-general
wrote:
> On 07/02/2017 07:01 PM, Ismael Bouya wrote:
>> (Mon, Jul 03, 2017 at 12:29:44AM +0200) Morten Linderud :
>>> But HTTPS doesnt matter here. We have a trusted signer inn the PKGBUILD,
>>> anyone can MITM for the good of their life.
>>> Unless they can fake the signature (Hint; they cant), or trick Lennart into
>>> signing something he shouldnt (Hint; he
>>> wont), we don't have a case here. It doesn't really matter if its HTTP or
>>> HTTPS.
>>>
>>> You also didn't really reply about the threat model.
>>
>> If I understand correctly what Nicohood meant,
>> what could happen is that version X of systemd (or anything else) has a
>> well known vulnerability, fixed in X+1. X+1 is packaged, so anyone
>> up to date thinks "good I'm safe now". But since a man in the middle can
>> force to download version X (signed by the systemd maintainer so
>> considered "secure"), he can force you to download that version when you
>> create the package and you'll think you have the safe version while
>> having the unsafe one.
>
> Okay, this I am genuinely curious about.
>
> In what circumstances can I have:
> - the systemd repository cloned over the git:// protocol
> - an annotated tag for systemd v233 signed by Lennart Poettering.
> - an annotated tag for systemd v232 signed by Lennart Poettering.
> - a man in the middle attack
> - `git verify-tag --raw v233` reports a GOODSIG with a VALIDSIG
> ${fingerprint} that matches with Lennart's known GPG fingerprint as
> recorded in validpgpkeys
>
> And as a result, when I run the git command `git checkout
> refs/tags/v233`, I am tricked into getting v232 instead which contains a
> vulnerability. Also, I wouldn't be alerted by the verbose printing of
> the systemd version which happens during the boot process, nor by
> $systemd_binary --version
>
> ...
>
> Because I don't think git works that way, but I am willing to be proven
> wrong. Also I bet the git developers would be fascinated to hear the
> details, you might even get some sort of bounty for successfully hacking
> git like that.
On the other hand,
the systemd-stable repo doesn't have signed tags (or commits) and Arch
is probably going to move to that since it has post-release fixes for
regressions and bugs.
--
damjan
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
On Sun, 2 Jul 2017 22:39:37 +0200, NicoHood wrote: >I've checked the links and while those suggestions are a bit harsh, >they are still valid: > >* btrfs-progs can use stronger hashes. Hi, the subject doesn't mention that "btrfs-progs can use stronger hashes", the subject actually is "Sébastien Luttringer and Tobias Powalowski". If you want to discuss a possible issue, open a new thread for e.g. "btrfs-progs can use stronger hashes". I didn't care about the links, since even without Eli's hint it was clear that this person is a known spammer. Florian has moderated her/his new account. Next time we simply should sent an off-list mail to arch-general-ow...@archlinux.org . On Sun, 2 Jul 2017 23:30:15 +0200, NicoHood wrote: >He reminds me a bit of Torvalds, from what I've heard. I haven't heard rumours about Linus Torvalds using disposable emails. Perhaps "User https://aur.archlinux.org/packages/apulse |grep 'Votes:') Votes: 82 Updated: Mon Jul 3 09:12:18 CEST 2017
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
(Sun, Jul 02, 2017 at 07:22:23PM -0400) Eli Schwartz via arch-general :
> Okay, this I am genuinely curious about.
>
> In what circumstances can I have:
> - the systemd repository cloned over the git:// protocol
> - an annotated tag for systemd v233 signed by Lennart Poettering.
> - an annotated tag for systemd v232 signed by Lennart Poettering.
> - a man in the middle attack
> - `git verify-tag --raw v233` reports a GOODSIG with a VALIDSIG
> ${fingerprint} that matches with Lennart's known GPG fingerprint as
> recorded in validpgpkeys
>
> And as a result, when I run the git command `git checkout
> refs/tags/v233`, I am tricked into getting v232 instead which contains a
> vulnerability.
Until there, it's exactly the topic of the presentation linked by
Nicohood
> Also, I wouldn't be alerted by the verbose printing of
> the systemd version which happens during the boot process, nor by
> $systemd_binary --version
Then you rely only on that last two things
--
Ismael
signature.asc
Description: PGP signature
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
On 07/02/2017 07:01 PM, Ismael Bouya wrote:
> (Mon, Jul 03, 2017 at 12:29:44AM +0200) Morten Linderud :
>> But HTTPS doesnt matter here. We have a trusted signer inn the PKGBUILD,
>> anyone can MITM for the good of their life.
>> Unless they can fake the signature (Hint; they cant), or trick Lennart into
>> signing something he shouldnt (Hint; he
>> wont), we don't have a case here. It doesn't really matter if its HTTP or
>> HTTPS.
>>
>> You also didn't really reply about the threat model.
>
> If I understand correctly what Nicohood meant,
> what could happen is that version X of systemd (or anything else) has a
> well known vulnerability, fixed in X+1. X+1 is packaged, so anyone
> up to date thinks "good I'm safe now". But since a man in the middle can
> force to download version X (signed by the systemd maintainer so
> considered "secure"), he can force you to download that version when you
> create the package and you'll think you have the safe version while
> having the unsafe one.
Okay, this I am genuinely curious about.
In what circumstances can I have:
- the systemd repository cloned over the git:// protocol
- an annotated tag for systemd v233 signed by Lennart Poettering.
- an annotated tag for systemd v232 signed by Lennart Poettering.
- a man in the middle attack
- `git verify-tag --raw v233` reports a GOODSIG with a VALIDSIG
${fingerprint} that matches with Lennart's known GPG fingerprint as
recorded in validpgpkeys
And as a result, when I run the git command `git checkout
refs/tags/v233`, I am tricked into getting v232 instead which contains a
vulnerability. Also, I wouldn't be alerted by the verbose printing of
the systemd version which happens during the boot process, nor by
$systemd_binary --version
...
Because I don't think git works that way, but I am willing to be proven
wrong. Also I bet the git developers would be fascinated to hear the
details, you might even get some sort of bounty for successfully hacking
git like that.
--
Eli Schwartz
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
(Mon, Jul 03, 2017 at 01:06:04AM +0200) Morten Linderud : > At this point we can't trust the trusted users to build and verify the > correct packages, let alone maintaine a safe infrastructure to build > packages. This is a slippery slope, and i really fucking hope this > isn't a serious issue any devs or TUs are afraid of. I didn’t imply that, but it’s easy to rely on the "gpg check" to skip other checks. I never faced the problem, but right out of my mind I don’t know how to download a git project archive and check easily that I got the correct tag. -- Ismael signature.asc Description: PGP signature
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
On Mon, Jul 03, 2017 at 01:01:35AM +0200, Ismael Bouya wrote: > (Mon, Jul 03, 2017 at 12:29:44AM +0200) Morten Linderud : > > But HTTPS doesnt matter here. We have a trusted signer inn the PKGBUILD, > > anyone can MITM for the good of their life. > > Unless they can fake the signature (Hint; they cant), or trick Lennart into > > signing something he shouldnt (Hint; he > > wont), we don't have a case here. It doesn't really matter if its HTTP or > > HTTPS. > > > > You also didn't really reply about the threat model. > > If I understand correctly what Nicohood meant, > what could happen is that version X of systemd (or anything else) has a > well known vulnerability, fixed in X+1. X+1 is packaged, so anyone > up to date thinks "good I'm safe now". But since a man in the middle can > force to download version X (signed by the systemd maintainer so > considered "secure"), he can force you to download that version when you > create the package and you'll think you have the safe version while > having the unsafe one. > > If that happens to the packager in archlinux, then you poisoned all > archlinux users. > > (but then, the md5sum will be wrong anyway?) > -- > Ismael At this point we can't trust the trusted users to build and verify the correct packages, let alone maintaine a safe infrastructure to build packages. This is a slippery slope, and i really fucking hope this isn't a serious issue any devs or TUs are afraid of. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
(Mon, Jul 03, 2017 at 12:29:44AM +0200) Morten Linderud : > But HTTPS doesnt matter here. We have a trusted signer inn the PKGBUILD, > anyone can MITM for the good of their life. > Unless they can fake the signature (Hint; they cant), or trick Lennart into > signing something he shouldnt (Hint; he > wont), we don't have a case here. It doesn't really matter if its HTTP or > HTTPS. > > You also didn't really reply about the threat model. If I understand correctly what Nicohood meant, what could happen is that version X of systemd (or anything else) has a well known vulnerability, fixed in X+1. X+1 is packaged, so anyone up to date thinks "good I'm safe now". But since a man in the middle can force to download version X (signed by the systemd maintainer so considered "secure"), he can force you to download that version when you create the package and you'll think you have the safe version while having the unsafe one. If that happens to the packager in archlinux, then you poisoned all archlinux users. (but then, the md5sum will be wrong anyway?) -- Ismael signature.asc Description: PGP signature
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
On Mon, Jul 03, 2017 at 12:25:22AM +0200, NicoHood wrote: > On 07/03/2017 12:21 AM, Morten Linderud wrote: > > On Mon, Jul 03, 2017 at 12:16:53AM +0200, NicoHood wrote: > >> On 07/03/2017 12:07 AM, Morten Linderud wrote: > >>> On Sun, Jul 02, 2017 at 11:55:35PM +0200, NicoHood wrote: > Yes the GPG signature of the tag commit is checked. However you can > attack the git metadata and set a tag to a different commit. If this > commit is signed, but at an older stage which is vulnearable, we have an > issue. Just one example. So we should always also secure the transport > layer. > https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias > > >>> > >>> The sign includes the hash. You would essentially have to trick Lennart > >>> into replacing the tag to a different commit, > >>> and sign the tag. Creating a vulnerable but verified source for the > >>> PKGBUILD. At this point i think we have bigger > >>> problems then whatever the PKGBUILD is doing... > >>> > >> > >> Thats is exactly what I mean. If I understood right you can modify the > >> git metadata in a way that you can pull tag 1.2 but get 1.0. And tag 1.0 > >> is gpg signed and all valid. This seems to work for me. > >> > > > > But at this point you can't trust critical maintainers of important > > software. This isn't a threat model i think > > PKGBUILDs (or Arch for that matter) really cares about. Am i wrong? Or are > > you implying MITM attacks can trick the > > packager into packaging broken software? > > > > > > Sure it is all about MITM, as we are talking about using https over > http. I am not sure if I am right. But why are we even discussing if > https is available? It will just make things better. > But HTTPS doesnt matter here. We have a trusted signer inn the PKGBUILD, anyone can MITM for the good of their life. Unless they can fake the signature (Hint; they cant), or trick Lennart into signing something he shouldnt (Hint; he wont), we don't have a case here. It doesn't really matter if its HTTP or HTTPS. You also didn't really reply about the threat model. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
On 07/03/2017 12:21 AM, Morten Linderud wrote: > On Mon, Jul 03, 2017 at 12:16:53AM +0200, NicoHood wrote: >> On 07/03/2017 12:07 AM, Morten Linderud wrote: >>> On Sun, Jul 02, 2017 at 11:55:35PM +0200, NicoHood wrote: Yes the GPG signature of the tag commit is checked. However you can attack the git metadata and set a tag to a different commit. If this commit is signed, but at an older stage which is vulnearable, we have an issue. Just one example. So we should always also secure the transport layer. https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias >>> >>> The sign includes the hash. You would essentially have to trick Lennart >>> into replacing the tag to a different commit, >>> and sign the tag. Creating a vulnerable but verified source for the >>> PKGBUILD. At this point i think we have bigger >>> problems then whatever the PKGBUILD is doing... >>> >> >> Thats is exactly what I mean. If I understood right you can modify the >> git metadata in a way that you can pull tag 1.2 but get 1.0. And tag 1.0 >> is gpg signed and all valid. This seems to work for me. >> > > But at this point you can't trust critical maintainers of important software. > This isn't a threat model i think > PKGBUILDs (or Arch for that matter) really cares about. Am i wrong? Or are > you implying MITM attacks can trick the > packager into packaging broken software? > > Sure it is all about MITM, as we are talking about using https over http. I am not sure if I am right. But why are we even discussing if https is available? It will just make things better. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
On Mon, Jul 03, 2017 at 12:16:53AM +0200, NicoHood wrote: > On 07/03/2017 12:07 AM, Morten Linderud wrote: > > On Sun, Jul 02, 2017 at 11:55:35PM +0200, NicoHood wrote: > >> Yes the GPG signature of the tag commit is checked. However you can > >> attack the git metadata and set a tag to a different commit. If this > >> commit is signed, but at an older stage which is vulnearable, we have an > >> issue. Just one example. So we should always also secure the transport > >> layer. > >> https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias > >> > > > > The sign includes the hash. You would essentially have to trick Lennart > > into replacing the tag to a different commit, > > and sign the tag. Creating a vulnerable but verified source for the > > PKGBUILD. At this point i think we have bigger > > problems then whatever the PKGBUILD is doing... > > > > Thats is exactly what I mean. If I understood right you can modify the > git metadata in a way that you can pull tag 1.2 but get 1.0. And tag 1.0 > is gpg signed and all valid. This seems to work for me. > But at this point you can't trust critical maintainers of important software. This isn't a threat model i think PKGBUILDs (or Arch for that matter) really cares about. Am i wrong? Or are you implying MITM attacks can trick the packager into packaging broken software? -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
On 07/03/2017 12:07 AM, Morten Linderud wrote: > On Sun, Jul 02, 2017 at 11:55:35PM +0200, NicoHood wrote: >> Yes the GPG signature of the tag commit is checked. However you can >> attack the git metadata and set a tag to a different commit. If this >> commit is signed, but at an older stage which is vulnearable, we have an >> issue. Just one example. So we should always also secure the transport >> layer. >> https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias >> > > The sign includes the hash. You would essentially have to trick Lennart into > replacing the tag to a different commit, > and sign the tag. Creating a vulnerable but verified source for the PKGBUILD. > At this point i think we have bigger > problems then whatever the PKGBUILD is doing... > Thats is exactly what I mean. If I understood right you can modify the git metadata in a way that you can pull tag 1.2 but get 1.0. And tag 1.0 is gpg signed and all valid. This seems to work for me. I've added sangy to this email, he is the author of this presentation and should know best. sangy, can you please give us some more detailed information if an attack could still compromise the systemd package with a modified git source but still gpg signed commits? ~Nico signature.asc Description: OpenPGP digital signature
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
On Sun, Jul 02, 2017 at 11:55:35PM +0200, NicoHood wrote: > Yes the GPG signature of the tag commit is checked. However you can > attack the git metadata and set a tag to a different commit. If this > commit is signed, but at an older stage which is vulnearable, we have an > issue. Just one example. So we should always also secure the transport > layer. > https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias > The sign includes the hash. You would essentially have to trick Lennart into replacing the tag to a different commit, and sign the tag. Creating a vulnerable but verified source for the PKGBUILD. At this point i think we have bigger problems then whatever the PKGBUILD is doing... -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
I stand corrected which leaves only part of my last sentence. Thanks for the detailed heads-up, everyone, especially Eli. On Sun, Jul 2, 2017 at 11:05 PM, Martin Kühne wrote: > we'll have to decide how we can deal with content like this in a way > that tells the source to go f themselves [content is hereby retracted]... have a good night and new week, everyone. except User: go f yourself. cheers! mar77i
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
On 07/02/2017 11:38 PM, Eli Schwartz wrote: > Let's make this clear: None of these claims are true! At all! Not even > one of them! You just say its not true, but that is wrong. I've wrote a statement for every link he pointed out in which way it is valid or not. > You have grabbed the troll bait! Please don't do that. Also, you're wrong. You are also a troll, as you just block with "STOP TROLLING". That is even more annoying to me. > 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. Yes, we should not shame specific people, I've learned this myself. He picked a few packages from few maintainers. We DO have SERIOUS security issues in PGBUILDs that we CAN fix, but just dont, because of no obvious reason. > 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. Yes the GPG signature of the tag commit is checked. However you can attack the git metadata and set a tag to a different commit. If this commit is signed, but at an older stage which is vulnearable, we have an issue. Just one example. So we should always also secure the transport layer. https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias You are just complaining the loudest. Doesnt mean you are right, nor better. If we just fix our PKGBUILDs, noone can troll. How do you think can we improve the PKGBUILD security if we reject suggestions like this? What would be your plan? Waiting for an attacker to proof that we should have fixed our PKGBUILDs earlier? signature.asc Description: OpenPGP digital signature
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
... 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 signature.asc Description: OpenPGP digital signature
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
On 07/02/2017 11:05 PM, Martin Kühne via arch-general wrote: > On Sun, Jul 2, 2017 at 10:39 PM, NicoHood wrote: >> 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. > > https://lists.archlinux.org/pipermail/arch-general/2017-July/043860.html > > You know I thought about the factuality part of the emails writing my > response too, and it turned out I couldn't criticise the content for > anything but harshness. This is going to an interesting place, and > we'll have to decide how we can deal with content like this in a way > that tells the source to go f themselves while paying actual attention > to valid criticism... > > cheers! > mar77i > You are right. I think this has all its past and we should just go on and fix our Distribution. He reminds me a bit of Torvalds, from what I've heard. It has its pro and its cons. We should use those suggestions, as they are really helpful. Actually it is really good to have someone carefully reviewing and watching our PKGBUILDs. As another idea we maybe could consider to write more precise PKGBUILD standards for security measures, which e.g. define that HTTPS must be used, whenever available etc. This way people like him can be of a huge help and we can improve our PKGBUILD security continuously. This would help everyone. How about that? ~Nico signature.asc Description: OpenPGP digital signature
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
On Sun, Jul 2, 2017 at 10:39 PM, NicoHood wrote: > 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. https://lists.archlinux.org/pipermail/arch-general/2017-July/043860.html You know I thought about the factuality part of the emails writing my response too, and it turned out I couldn't criticise the content for anything but harshness. This is going to an interesting place, and we'll have to decide how we can deal with content like this in a way that tells the source to go f themselves while paying actual attention to valid criticism... cheers! mar77i
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
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 signature.asc Description: OpenPGP digital signature
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
On Sun, 2 Jul 2017 16:18:23 -0400, Eli Schwartz via arch-general wrote: >So basically, you are confirming you are fnodeuser? IMO it's better not to reply to her/him and instead to inform arch-general-ow...@archlinux.org , just in case it wasn't already noticed. https://lists.archlinux.org/pipermail/arch-general/2017-July/043853.html https://lists.archlinux.org/pipermail/arch-general/2017-July/043854.html
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
On 07/02/2017 04:21 PM, G. Schlisio wrote: > Oh, please dont feed the troll… its exactly what he's aiming for. I thought it was important that everyone know exactly who they are dealing with (because he has a lot of history here and has now progressed to hiding his name/handle). Otherwise I wouldn't have replied at all. So yeah, the fact that this is fnodeuser again is the only observation I have to make this time. :) -- Eli Schwartz signature.asc Description: OpenPGP digital signature
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
Am 02.07.2017 um 22:18 schrieb Eli Schwartz via arch-general: > 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. > Oh, please dont feed the troll… its exactly what he's aiming for.
Re: [arch-general] Sébastien Luttringer and Tobias Powalowski
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. -- Eli Schwartz signature.asc Description: OpenPGP digital signature
[arch-general] Sébastien Luttringer and Tobias Powalowski
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.
