
On 30-04-2015 09:21, Michael Snoyman wrote:
On Thu, Apr 30, 2015 at 10:08 AM Jeremy
wrote: Mathieu Boespflug-4 wrote
We're not introducing dependencies on dynamically linked system libraries that makes tooling hard to distribute. We're not asking users to install anything new that isn't already a staple of most developer desktops
My sole concern with this is that git is often not present on build servers, which may be minimal cloud VMs. Here's what I get when I try to install git on mine:
# apt install git --no-install-recommends ... The following NEW packages will be installed: git git-man libcurl3-gnutls liberror-perl libexpat1 libgdbm3 perl perl-modules 0 upgraded, 8 newly installed, 0 to remove and 2 not upgraded. Need to get 10.4 MB of archives. After this operation, 57.2 MB of additional disk space will be used.
Not unbearable, but not insignificant either.
One possible workflow[1] would be to have a dedicated system that uses Git and GPG to pull the current versions of all packages and verify signatures. That system could then create a snapshot of that information that could simply be downloaded by a build server. In fact, there could even be a public server available providing that functionality, with the caveat that- like today- you'd need to trust that server to not be compromised.
Isn't this just another moving part? (Moving parts are generally considered bad news when you're trying to engineer a secure system.) And has there been any review of git wrt. if it is robust to malicious servers? (E.g. if I do a "git fetch", can the server I happen to be talking to just spew data at the client indefinitely to, for example, fill up its disk or to prevent it from ever progressing?) Regards,