Okay, thank you for being patient. My deadlines passed last night and I'm starting to dig out...
* What are your recommendations for the targets/* topology? > - If we use simply gem names (not full name-version-platform tuples or > strings), then I think the revocation model requires a rewrite of a whole > target metadata be rewritten after target key compromise. This may be > acceptable, however, > Yes, you may need to do this in this case. In our thinking, a targets role would map to a project. So the root would end up revoking a key from a specific target and the list of trusted target keys would change. If I'm the developer of a different target, my key / targets.txt does not need to change. > - If we use targets/gemname/version-platform then we can rewrite > targets/gemname.txt to disallow future publishing using compromised keys, > but existing (non-malicious) gemname/version-platform.txt remain valid. Is > this the case, and is this safe? (assuming all other standard roles) > I suppose you could try to do things in this way (I don't know if it is safe). However, I think the more natural way to do what you want to do is make it so that older packages (only) are still trusted even if the key is later compromised. Instead, I would recommend revoking the compromised targets key and then signing the old packages with the new key. (Apologies if I'm misunderstanding this.) > - The paper loosely suggests in the language having these map to files, > which makes sense, but is somewhere between the above two options, and > requires new targets to be issued regularly (maybe that is a good thing?). > You can require targets to be reissued using TUF by setting expirations appropriately. Short expiration would require these keys to be online (or close to it). If you do this, you're trading timeliness (how long can someone get told an old version is current) for risk (how easy is it for someone to steal your key). > - There are some scaling concerns with each different approach that we > may need to consider. In any of the latter cases, release.txt will continue > to grow fast, although gzip and such will also continue to work well. At > some point though, parsing becomes slow and/or memory intensive. * The paper mentions the metadata files for 8000 PyPI binaries reaching > several megabytes. We have considerably more data than this, as such we may > very much need to alter both the data format, and possibly slice the files > into pieces. Do you have any particular recommendations in this area? Are > there non-obvious key security considerations here (I think most are > covered by timestamp.txt and release.txt)? > You can split things up via delegating trust. There isn't just one targets file which will simplify this tremendously. > * Given the existence of the release and higher level targets roles in > this system, do you still strongly recommend leaf-targets (e.g. > targets/gems/rails-3.2.0-ruby.txt) be rewritten in the event of a > compromise of the rails key that signed it (in the event of t=1)? > yes, absolutely. If compromise means that someone else has the rails key, they can act as a MITM for anyone getting updates and compromise all users that retrieve the package. Compromises should be rare, or at least much rarer than normal updates, so this shouldn't be a major performance or scalability worry. > * There is scope in the metadata, for two roles to have the same paths or > path patterns. Is it recommended such an event be a validation error? > Is there a reason why you would logically want this to occur? I would say that it seems both potentially useful and suspicious. Raising an error, but having a flag to override and continue may make sense. (I'm just pulling this out of the air though.) In the next week or so, we can get a setup together where you can play more with TUF and see how it works in different scenarios yourselves. We're starting to get into discussion with the PyPI folks too so our time is a little divided, but we'll do what we can to show you what a realistic deployment might look like. Thanks, Justin P.S. If you'd like to open your google doc for comments, I have a few other things I could mention there. _______________________________________________ RubyGems-Developers mailing list http://rubyforge.org/projects/rubygems RubyGems-Developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
