Le 07/01/2017 à 16:05, NicoHood a écrit :
Hey Bruno, nice to hear that you want to join the great ArchLinux project as TU. I am aware the discussion period has not started yet, but I think its fine if I already give some feedback.
Hi Nico, You’ve been very fast indeed, but the discussion period started right after anyway. ;)
I've checked your PKGBUILDs and I've noted a few thinks (which I also did wrong or sometimes forget). Those are mostly only concerning security aspects which I find important. If you followed the recent discussion you might have noticed that some people differ from this opinion. Please take it as a kind notice for you, use it if you wish :)
* For github download .tar.gz is preferred over .zip in general if i am not wrong.
Assuming you refer to audiothumbs-frameworks and ring-kde, I wasn’t aware GitHub was providing .tar.gz downloads for snapshots tarballs (they are not provided in the UI), but I admit not having tried a simple substitution of file extension, which indeed works. Strange lack of curiosity from my part. I’ve fixed both of them, thanks!
* Prefix your source download with: ${pkgname}-${pkgver}.tar.xz:: if you have a common SRCDIR. I also recently change to a common src dir, as too many packages blow my directories.
Can you please specify which package(s) you have in mind here? I’ve just checked again and didn’t found any package where I don’t do this and upstream tarball doesn’t follow this either.
* You can use https for sourceforge downloads soon/now[1] (bs1770gain)
Yes, and that is already what I do. Maybe you’ve overlooked or are talking of “Upstream URL” (in which case this doesn’t work).
* Thanks for using sha256sums. You may want to use the even stronger sha512sums, as it does not hurt to use stronger hashes *duck*
Stronger is relative (they’re mathematically the sames, breaking one in an applicable way probably means breaking both). Does not hurt too. Everything has been said around this in this list some months ago, I’ll not start that debate again. I’ll only provide sha512 if this is what upstream provides or a new policy going that way is adopted by ArchLinux, which currently isn’t the case AFAIK.
* certbot-user: the gpg keys should have a comment with the owner of the trusted keys (as you did with exfalso, but with email)
Sure, fixed. :) I’ve also fixed it in scribus-devel where it has apparently escaped your review. ;)
* mpd-{sserver,}minimal uses a sha1sum. If its an upstream hash please contact them to use stronger hashes and include a stronger one as well. You can use multiple hashes in the PKGBUILD (as in weboob-headless).
Like most of my -light or -minimal packages, hashes are from the repo package. When they are upstream ones too (KDE packages notably), I verify them, but here it’s not the case AFAIK. Those packages also use a PGP key, so I could remove the sum altogether as the wiki proposes. But actually this is one almost valid use case where I agree on switching to stronger checksum: packages being on AUR, and AUR being full of people that don’t understand PGP and its support in makepkg, the use of --skippgpcheck is probably frequent. Then, even if this is not a behaviour to be encouraged, having a strong verified checksum here is probably better for those users. I’ve thus switched them to sha256sums. That way, people relying on PGP still get the full verification, while people skipping it get a checksum that I’ve computed after PGP verification of the same tarball.
* powerdevil/spectacle-light uses http downloads. Even though gpg signatures are used, it would be nice to have https available anyways. It seems kde missconfigured their download subdomain for https, so you might want to contact them about that?
Yes, KDE doesn’t provides https at the moment. I’ve reported a bug upstream[0] (failed to find any open or close one relating to this).
* What I also do is to put my own GPG ID inside my PKGBUILDs, so people can simpler verify/find my key. Just as an idea.
What purpose does that serve (outside of cluttering the PKGBUILD)? My fingerprint is already in my AUR account profile[1] for that matter.
* For those projects who dont use GPG signatures yet, you might want to kindly contact them. I've written a script + instructions for using gpg along with a template to contact upstreams[2]. You might want to check it out.
And I don’t like it. Because (good) PGP is not easy, and PGP signatures for the sake of PGP signatures are not a good idea. If you want to be able to trust a sig, you need to trust the key and the behaviour of his owner regarding PGP. And I won’t trust a sig issued by someone that only did it to satisfy you, rather than deeply thought about it and its implications. Also, automated is rarely a good idea when it comes to PGP.
* If you want to move whipper, please consider to take part in the discussion about gpg[3]. Please dont take it personally, some people found them personally offended, while this was not the intention. You have the chance to also speak up for stronger security. I do not want to end this in an offtopic discussion, maybe you can help too ;)
Done. But as you might have expected since last paragraph, didn’t went your way. Regards, Bruno [0] https://bugs.kde.org/show_bug.cgi?id=374741 [1] https://aur.archlinux.org/account/ArchangeGabriel/