search

mozilla / dinobuildr

A macOS deployment utility developed by Mozilla IT
Mozilla Public License 2.0
28 stars 24 forks source link

Feature: Break out Moz specific attributes into config file(s) #150

Open n3philim opened 5 years ago

n3philim commented 5 years ago

Break out Mozilla specific attributes (i.e. path to our Github, manifest names) from dino_engine.py into config files

luciusbono commented 5 years ago

I actually sat down and looked at this for the first time in a long time: a config file would be relatively easy to do since we're just replacing some defaults, but there is a chicken-and-egg issue that needs to be solved. dinobuildr would have to be told what repo / org it's being used from so it could infer the location of it's own config file. This is actually possible with the work that was done to support external repos, since the downstream dinobuildr.sh script actually passes org / repo information into dino_engine.py - but at some point we're just moving the problem around.

I'm focusing on removing the requirement to hash the manifest files, which means that nobody should have to dig through dino_engine.py on a regular basis. Config files are still the right thing to do long term, but ultimately it's not going to be as big of an issue.

tristanthomas commented 5 years ago

@luciusbono are you referring to moving the hash value of the manifest files to the config files or totally removing hash checks for the manifest files?

I should probably dust off this old branch: https://github.com/mozilla/dinobuildr/tree/feat-config-file

Reminder to self, swap out exec and just append then read from a dictionary instead. https://github.com/mozilla/dinobuildr/blob/918be4c2a97be19e348cd0aa4657d1ab33f569a0/config.py#L101

luciusbono commented 5 years ago

What I'm proposing is actually just fully removing the hash checks for the manifest - while I think confirming the validity of every component that dinobuildr downloads from the internet is good practice, this check is most useful if:

A) Someone gains access to the Github repo and makes unapproved changes of the manifest B) Github serves up erroneous content when asked for a file C) The file is downloaded in an incomplete state

The biggest leap of faith we take is trusting the initial bootstrapping script to pull down the correct upstream script. Honestly, until we sign this script that's just going to be a sketchy maneuver. Once we've started executing dinobuildr, we're trusting Github to serve us the correct content - which I think is correct. The extra hoop one has to jump through to update the hash in dino_engine.py is a barrier to contribution. We'd talked about this many times I believe, but when training some folks in EUS to develop dinobuildr it finally was clear to me that we could just make this change safely 😄

This significantly simplifies the config file. A future state where changes to dinobuildr are made with some kind of trusted local binary that does all the hash checking for the administrator could see the return of the manifest hash I think. We should discuss sometime!