Just as a word of calming against this our recommended patterns are to make the payload you're fetching configurable:
such as fetch this particular tarball from server X with a shipping SHA1/SHA256 sum of the payload to ensure a) its the same payload b) it wasn't corrupted from the point of writing the charm to upgrading. Shipping these upgrades via charm config leaves existing deployments at their version, only new deployments will upgrade the components, and users are still left to "manually upgrade" by changing the charm config, which should keep you from seeing major breakage unless shipping components contain the defect as outlined above. The charm should handle upgrades, vs the user 'creating' the change. The GPG approach is interesting, as its replicates some of the "trusted registry" features i've been tracking on the app container side, where we have warm fuzzies knowing that our image passes a validity hash match, and further is verified against the developers signature w/ the hub, so we know they signed the release. I like these ideas, keep up the good work @cory Charles Butler <charles.but...@canonical.com> - Juju Charmer Come see the future of datacenter orchestration: http://jujucharms.com On Thu, Jan 14, 2016 at 7:36 AM, Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > Please note that this doesn't have to be a burden on the vetting process. > The vetting process for an updated binary can be more or less automated, > especially with the upcoming juju resources. The important part is that > every time the binary changes, the charm version has to be bumped. > > 2016-01-14 13:29 GMT+01:00 Merlijn Sebrechts <merlijn.sebrec...@gmail.com> > : > >> hi all, Sorry to barge in like this, but this is very important for my >> use-case. >> >> >> Binaries that are downloaded always need to be checked using a checksum >> *included >> in the charm*. >> >> One Charm version should always deploy the *exact same version of that >> service*. If you want Juju to be used in production, *Charm deployment >> has to be reproducible*. Please do not force people who use Juju in >> production to fork all the Charms they use. Store Charms should be good >> enough so they can be used in production. >> >> Consider the use-case of a platform that automatically scales a service >> up and down depending on usage. This will break if we allow Charms to be >> changed between versions. This has bitten me once already. The Hadoop >> Charms downloads the jujubigdata pip dependency and uses code in this >> dependency for communication between units. Because of an oversight, two >> versions of this pip dependency were not compatible with each other. This >> meant that running `juju add-unit` on an existing Hadoop installation was >> successful one day and failed the next. >> >> I understand why the Hadoop Charms were build this way, it is a lot >> easier to maintain. However layers fix the maintenance issue. >> >> We do not know who uses our Charms and for what, so *there is no way we >> can reliably determine if a change would break a use case*. Yes, this >> change could fix a bug but there could be some service relying on this bug >> to be present. Because of this, one version of a Charm must always deploy >> the exact same thing. Let the users handle the upgrade process themselves. >> >> There are examples enough of cases where even minor version changes of >> binaries break relationships, so one version of a charm must always deploy >> the same binary. >> >> >> >> Kind regards >> Merlijn Sebrechts >> >> 2016-01-14 12:42 GMT+01:00 Cory Johns <cory.jo...@canonical.com>: >> >>> My preference over hard-coding a checksum into the charm would be >>> hosting a GPG signature alongside the file and including the public key in >>> the charm. This allows the charm author to update a file if necessary >>> without having to also update the charm, but also allows the charm to >>> confirm that it got the file as intended by the author. >>> >>> Hopefully, though, this will become moot with the advent of resources >>> support in Juju 2.0. >>> >>> On Thu, Jan 14, 2016 at 1:48 AM, Andrew Wilkins < >>> andrew.wilk...@canonical.com> wrote: >>> >>>> On Thu, Jan 14, 2016 at 3:23 AM José Antonio Rey <j...@ubuntu.com> >>>> wrote: >>>> >>>>> I think this is more of a discusion on if you got 'what' you wanted or >>>>> if you got it from 'where' you wanted. Even if you used SFTP, the file >>>>> could've changed, and if it doesn't have a SHA1SUM it could result in >>>>> unexpected charm breakage. >>>>> >>>>> If it were me, I would always implement SHA1SUMS, just to make sure >>>>> that >>>>> the file is, in fact, what I wanted. It would make it easier to debug >>>>> and fix later down the road. >>>>> >>>> >>>> +1 >>>> >>>> SFTP/SSH will (can?) ensure the integrity during transit, but can't >>>> tell you that the data wasn't tampered with outside of the SFTP transfer >>>> process. Someone could have replaced the file on the file server. The >>>> client needs to know ahead of time what to expect. >>>> >>>> On 01/13/2016 02:18 PM, Adam Israel wrote: >>>>> > Matt, >>>>> > >>>>> > For the charm in question, I would think adding the sha1sum check to >>>>> the >>>>> > process would be sufficient, especially in the scenario that the >>>>> binary >>>>> > is being self-hosted for the purposes of installing it via the charm. >>>>> > >>>>> > Adam Israel - Software Engineer >>>>> > Canonical Ltd. >>>>> > http://juju.ubuntu.com/ - Automate your Cloud Infrastructure >>>>> > >>>>> >> On Jan 13, 2016, at 2:14 PM, Tom Barber <t...@analytical-labs.com >>>>> >> <mailto:t...@analytical-labs.com>> wrote: >>>>> >> >>>>> >> Yeah but as pointed out earlier, it verifies where you got it from, >>>>> >> but not what you got. :) >>>>> >> >>>>> >> On 13 Jan 2016 19:11, "Jay Wren" <jay.w...@canonical.com >>>>> >> <mailto:jay.w...@canonical.com>> wrote: >>>>> >> >>>>> >> StrictHostKeyChecking and shipping the public key of the ssh >>>>> host with >>>>> >> the charm does seem to meet the criteria of verifying the >>>>> intended >>>>> >> source. >>>>> >> >>>>> >> >>>>> >> On Wed, Jan 13, 2016 at 1:46 PM, Matt Bruzek >>>>> >> <matthew.bru...@canonical.com >>>>> >> <mailto:matthew.bru...@canonical.com>> wrote: >>>>> >> > I recently reviewed a charm that is using sftp to download the >>>>> >> binary files >>>>> >> > with a username and password. The charm does not check the >>>>> >> sha1sum of these >>>>> >> > files. >>>>> >> > >>>>> >> > The Charm Store Policy states: Must verify that any software >>>>> >> installed or >>>>> >> > utilized is verified as coming from the intended source >>>>> >> > >>>>> >> > https://jujucharms.com/docs/stable/authors-charm-policy >>>>> >> > >>>>> >> > Does using sftp eliminate the need to check the sha1sum of >>>>> the files >>>>> >> > downloaded? >>>>> >> > >>>>> >> > What does the Juju community say to this question? >>>>> >> > >>>>> >> > - Matt Bruzek <matthew.bru...@canonical.com >>>>> >> <mailto:matthew.bru...@canonical.com>> >>>>> >> > >>>>> >> > -- >>>>> >> > Juju mailing list >>>>> >> > Juju@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com> >>>>> >> > Modify settings or unsubscribe at: >>>>> >> > https://lists.ubuntu.com/mailman/listinfo/juju >>>>> >> > >>>>> >> >>>>> >> -- >>>>> >> Juju mailing list >>>>> >> Juju@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com> >>>>> >> Modify settings or unsubscribe at: >>>>> >> https://lists.ubuntu.com/mailman/listinfo/juju >>>>> >> >>>>> >> -- >>>>> >> Juju mailing list >>>>> >> Juju@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com> >>>>> >> Modify settings or unsubscribe at: >>>>> >> https://lists.ubuntu.com/mailman/listinfo/juju >>>>> > >>>>> > >>>>> > >>>>> >>>>> >>>>> -- >>>>> José Antonio Rey >>>>> >>>>> >>>>> -- >>>>> Juju mailing list >>>>> Juju@lists.ubuntu.com >>>>> Modify settings or unsubscribe at: >>>>> https://lists.ubuntu.com/mailman/listinfo/juju >>>>> >>>> >>>> -- >>>> Juju mailing list >>>> Juju@lists.ubuntu.com >>>> Modify settings or unsubscribe at: >>>> https://lists.ubuntu.com/mailman/listinfo/juju >>>> >>>> >>> >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >>> >> > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
