On Tue, Nov 29, 2016 at 01:04:47AM +0100, Levente Polyak wrote:
On 11/29/2016 12:29 AM, Baptiste Jonglez wrote:
- you should use git+https:// instead of plain git:// even through the CA world is a bit wonky it still authenticates the server and at the very bare minimum adds confidentiality.
I don't like the "everything-over-HTTP(S)" approach in general, especially when there is a dedicated protocol that works (yes, I know, this is basic ranting).
Assuming the git revision is identified by a commit hash, I see no value in using HTTPS for authentication or verification. I agree it is useful however when building from a tag or a branch, as you correctly pointed out for another package.
On the other hand, if one day the TLS certificate becomes invalid (expired certificate, untrusted CA, etc), the package would fail to build. I see this as a significant drawback of using git+https://.
Well pulling over TLS was discussed over and over and over and over again and we ended up that we just do it for all of our packages if available... Thats why this came up in the first place: https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/
Yes, I saw the discussion on arch-dev-public (but obviously could not participate).
I quote dave: "Security is not a binary thing". It adds another layer of security, if you like it or not. It authenticates the server (yes there may be untrusted CA, so? *shrug*) and i repeat again: at the very bare minimum adds confidentiality. Feel free to re-read the arch-dev-public thread, the outcome was the mentioned todo list.
I heard a lot of opinions and some of them are understandable... but saying that its a significant drawback as the certificate could possible be invalid/expired is certainly nothing i would _ever_ consider as such.
For a package in [community], an expired certificate for the upstream tarball is not a big deal, since it does not directly affect the Arch user installing the package. As a packager, you can just get the tarball by some other means, or wait a few days so that somebody renews the cert. But for the AUR, an expired certificate would be annoying, as any user trying to build the package (e.g. using an AUR helper) would encounter an error.
I never get why people always make such a big fuzz in not pulling over TLS. The same argumentation could be used for the regular tarballs and I repeat, the outcome is simple: use https, easy as that.
Well, I agree with the outcome of the discussion, which was basically "One way or the other does not change much security-wise, so let's switch to HTTPS if doing so does not require significant efforts".
ring-gnome-git - a VCS package should always provide its non-VCS package variant like 'ring-gnome'
Actually, the missing "provides" is intended. The Ring components are interdependent and get updated quite frequently, so at any given time `ring-foo` and `ring-foo-git` are likely offer a different API/ABI.
More practically, when the "provides" was here, I had issues with AUR users mixing -git and non-git ring packages and complaining of building errors.
This could be the case for literally _any_ library f.e. and still all of them have their corresponding provides. If there would be anything depending on ring-gnome you created an unresolvable hell be just conflicting it because it may have API changes.
libringclient-git - a VCS package should always provide its non-VCS package variant like 'libringclient' - If there is no strong reason to depend on a git variant, always depend on the non VCS, in this case ring-daemon instead of ring-daemon-git
See the above comment on gnome-ring-git.
And here is the -git hell I describes, either take all -git or none... that's not how it should be. Think how it would be if every library would be like that, that would mean you need to use -git for the whole system just because you switch a single package. Don't enforce it just because... if such happens people will figure.
Again, the constraints are a bit different on the AUR and on a binary repository. What I try to ensure is that somebody running e.g. "yaourt -S ring-gnome-git" will not have compilation issues. If ring-gnome-git depends on libringclient, then the former will not build if the API provided by libringclient has changed recently. But you're right, it's a mess. I updated the *ring*-git packages so that they only depend on non-git packages, and they now all provide their non-git version. Anyway, I was thinking of orphaning all those -git Ring packages, since I don't use them anymore and they take time to maintain. Baptiste