Re: [aur-general] [REVIEW REQUEST] python-viivakoodi
On 16-12-01 21:57:08, Eli Schwartz via aur-general wrote: > On 12/01/2016 08:24 PM, Quentin Bourgeois wrote: > > I finally managed to upload to AUR[0]. I had to made some > > modification[1] in order to pass the different hooks on the server but > > I think they would be ok. > > So I see... especially the "every commit must have a .SRCINFO". I had > kind of sort of assumed you would push the PKGBUILD you finally settled > on as the initial PKGBUILD, but apparently you opted to preserve your > learning experience for eternity. :p > > Unfortunately that won't work, since your learning experience included a > missing .SRCINFO which cannot be preserved. :D Indeed, I did a pretty bad job with that, which, was not tested enough. I will try to come up with a better solution by tomorrow. > > > Is it relevant to add some of this information > > (runtime deps on setuptools) ? I don't remember having seen such > > information while looking at the manpage/wiki. In the other hand I > > don't known if its obvious for other. > > Which manpage/wiki? I was thinking of the wiki page that give instruction with Python PKGBUILD[0]. > > I guess it is sort of assumed that people won't uninstall setuptools -- > it is part of the python package manager scene (distutils -> setuptools > -> pip) and in a way it sort of competes with pacman. > "The standard library is where modules go to die" but nevertheless, I am > pretty sure the setuptools developers would love to make sure everyone > always has it, no matter what. > > But I will admit it wasn't obvious to me... until I learned the basics > of python module packaging. > > -- > Eli Schwartz [0] https://wiki.archlinux.org/index.php/Python_PKGBUILD signature.asc Description: PGP signature
Re: [aur-general] TU Application: Baptiste Jonglez
On 02/12, Giancarlo Razzolini wrote: Em dezembro 2, 2016 11:18 NicoHood escreveu: The signature itself is only a signed hash (sha256). So we do rely on the collision resistance of sha256[1] (or whatever the GPG itself uses). You are right, that hashes themselves are not enough to verify that the original author provided this source. But it gives you the guarantee that you downloaded the same source, as the maintainer(PKGBUILD writer) did. GPG uses DSA[0]. And the signatures done using GPG are done in a way that requires a key pair on the part of the person doing the signature. The link you sent demonstrate precisely that. They are much more than simple hashes. [0] https://www.gnupg.org/gph/en/manual.html#AEN216 That's quite outdated, and RSA has been the default for quite a long time. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/ signature.asc Description: PGP signature
Re: [aur-general] TU Application: Baptiste Jonglez
>> >> Besides this issue, I already mentioned another drawback of using HTTPS: >> untrusted certificates (either expired, self-signed, or just signed by an >> untrusted CA) will cause build failure. This was a real issue for >> OpenWRT, so they switched to using --no-check-certificate in 2010 [1] to >> avoid build failures. Sources are already validated with a checksum. >> > > Well, relying only on checksums is not good enough in my opinion. We know > for a fact that hashing algorithms are built on top of *reasonable* chance > that collisions won't happen. Sure, the space of a SHA256 hash is huge, but > we must not just shrug over it. Because if we, as maintainers do, upstream > will think they don't need to provide signed sources, because hashes are > probably "good enough". > The signature itself is only a signed hash (sha256). So we do rely on the collision resistance of sha256[1] (or whatever the GPG itself uses). You are right, that hashes themselves are not enough to verify that the original author provided this source. But it gives you the guarantee that you downloaded the same source, as the maintainer(PKGBUILD writer) did. That is what integrity is all about, that is not only a checksum! The weakest spot though is the initial fetching of the source on which the maintainer relies on. However with strong hashes you can at least ensure that you (for a rebuild) download the exact same sources, as the maintainer did. You just cannot prove who published that source itself. Saying sha256 is not secure enough for that purpose would also say GPG is not safe. Correct me if I am wrong though. I'd be also nice to discuss this in the email I recently opened and not in the TU Application. I think this is a highly important topic, especially for those packages where we do not have gpg and https available and you can only rely on the hash that the maintainer gave out (AUR). [1]https://www.bestvpn.com/wp-content/uploads/2015/03/Digital_Signature_diagram.png Cheers Nico signature.asc Description: OpenPGP digital signature
[aur-general] Signoff report for [community-testing]
=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 0 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 2 fully signed off packages * 23 packages missing signoffs * 4 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == Incomplete signoffs for [community] (23 total) == * arm-none-eabi-newlib-2.4.0-4 (any) 0/2 signoffs * darktable-2:2.2.0rc1-1 (i686) 0/1 signoffs * devil-1.7.8-24 (i686) 0/1 signoffs * gimp-ufraw-0.22-9 (i686) 0/1 signoffs * keepalived-1.3.2-1 (i686) 0/1 signoffs * libasl-0.1.7-1 (i686) 0/1 signoffs * libfdk-aac-0.1.4.r88.5fd7e65-1 (i686) 0/1 signoffs * monitoring-plugins-2.2-1 (i686) 0/1 signoffs * openscenegraph-3.4.0-4 (i686) 0/1 signoffs * vagrant-1.9.0-1 (i686) 0/1 signoffs * vagrant-substrate-575.af28386-1 (i686) 0/1 signoffs * xv-3.10a-22 (i686) 0/1 signoffs * ziproxy-3.3.0-8 (i686) 0/1 signoffs * darktable-2:2.2.0rc1-1 (x86_64) 1/2 signoffs * devil-1.7.8-24 (x86_64) 0/2 signoffs * gimp-ufraw-0.22-9 (x86_64) 0/2 signoffs * keepalived-1.3.2-1 (x86_64) 0/2 signoffs * libasl-0.1.7-1 (x86_64) 0/2 signoffs * libfdk-aac-0.1.4.r88.5fd7e65-1 (x86_64) 0/2 signoffs * monitoring-plugins-2.2-1 (x86_64) 0/2 signoffs * openscenegraph-3.4.0-4 (x86_64) 0/2 signoffs * vagrant-substrate-575.af28386-1 (x86_64) 1/2 signoffs * ziproxy-3.3.0-8 (x86_64) 0/2 signoffs == Completed signoffs (2 total) == * vagrant-1.9.0-1 (x86_64) * xv-3.10a-22 (x86_64) == All packages in [community-testing] for more than 14 days (4 total) == * libfdk-aac-0.1.4.r88.5fd7e65-1 (i686), since 2016-11-10 * libfdk-aac-0.1.4.r88.5fd7e65-1 (x86_64), since 2016-11-10 * libasl-0.1.7-1 (i686), since 2016-11-10 * libasl-0.1.7-1 (x86_64), since 2016-11-10 == Top five in signoffs in last 24 hours == 1. hcartiaux - 2 signoffs 2. halosghost - 1 signoffs
