On Tue, May 17, 2016 at 04:25:06PM +0200, Daniël Mostertman wrote: > 3) Moving the certificates to -for example- /etc/apt/ssl/ would open up a > similar problem as point 1: Giving a non-privileged user,_apt, access to the > private keys. That should be a pretty safe operation. _apt is in no group (and shouldn't have one, so your 2) should be ruled out) by default, so chown'ing files to _apt:root and chmod'ing it to 400 (if you haven't already) is indeed the best option you have. We do this for the auth.conf file (= password storage) automatically as that is "our" file. In practice, that doesn't change a thing in terms of who can read that file as only root can "login" to the _apt user (password login is disabled; ssh and co don't work either if you don't go out of your way to "fix" it). What you could do is disabling privilege dropping for https (Binary::https::Debug::NoDropPrivs "true";), but I highly doubt this is an improvement in your security setup, I just mention it for completeness – not as a recommendation! > We believe that apt-get should read the private keys and certs > dropping privileges. That would be nice indeed, it isn't really possible in the current state of affairs through as we use libcurl for https and we can just tell it to use key+cert via setting the filenames as options – we can't control the time and place the files will be read. So the only thing we could do is create an _apt accessible copy of the private material in a temporary directory, which while in theory perfectly fine makes me feel a bit icky in practice as way too much magic for my taste… (We could of course also reimplement https without using libcurl… while I see some benefits there and it crosses my mind hence once in a while the prospect of maintaining it doesn't fill me with endless amounts of joy yet and it is not a small project to begin with…). > We also realise that we're probably one of the very few that both run a > private repository ánd use SSL client auth certs. You are right, but that isn't all to important in terms of reporting bugs. A bug is a bug is a bug: https://www.debian.org/Bugs/Reporting That said, I think this specific issue isn't a bug – at most its a wishlist item for implementing https differently as mentioned above, which I feel partial about having a report for open as such a report isn't really actionable much like other 'small' wishlist items like "acquire world domination"… Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature