Core Infrastructure Initiative (CII) Best Practices badge

[ypid]

Refer to: https://twit.tv/shows/floss-weekly/episodes/389 and https://bestpractices.coreinfrastructure.org

I am currently going thought the questions.

Project URL: https://bestpractices.coreinfrastructure.org/projects/237

[ypid]

Status: 59% https://bestpractices.coreinfrastructure.org/projects/237
I intent to finish the setup in the next 24 hours.

The project MUST have a publicly available archive for reports and responses for later searching. (URL required)

@drybjed Just curious. Have you setup github-backup to backup repos and issues? I have played with github-backup and contributed a bit but have not set it up yet.

[drybjed]

@ypid I haven't set up github-backup yet, but it might be a good task for the bot. I'll set that up and let you know.

[drybjed]

@ypid BTW, token generation in debops.pki could be switched to SHA256 so that we don't have the issue with broken cryptographic algorithms.

[ypid]

@drybjed

I haven't set up github-backup yet, but it might be a good task for the bot. I'll set that up and let you know.

Nice. Thanks.

BTW, token generation in debops.pki could be switched to SHA256

😄 Now that there is a incentive 😉 You are encouraged to do that. Choosing MD5 because it is faster was not a very strong argument in the first place.

[ypid]

Seems we are at a solid base of 71% (I have tried to not overestimate it and some criteria still need to be verified).

@drybjed Want to check the Analysis and Future sections which I did go thought right now? I would add the badge to this repo when you are OK with it.

[drybjed]

Looks good. I like it when you implied that configuration management would require STOPPING TIME ITSELF to be reproductible. :-) However, after checking the criteria:

This criterion does not apply if no building occurs (e.g., scripting languages where the source code is used directly instead of being compiled).

I don't believe that DebOps itself builds any binaries. There were some cases where Debian packages were built by DebOps, but each one is isolated and it depends on the package maintainer to ensure reproductible build. I would mark this entry as N/A.

[ypid]

Thanks for your feedback. I thought about that and stated in the first sentence how I do interpret reproducible builds for the project:

Reproducible builds for configuration management frameworks (like the DebOps project) could be interpreted as being able to produce two identical VM or container images by stripping out all non-deterministic/changing peaces.

So I don’t think that it is not applicable. Let me explain that a bit more. At work, I use DebOps to build a ownCloud appliance and I am working towards fully automated builds of this VM appliance with DebOps. So I am actually building an image which is later shipped to customers. I think it would be interesting to build this VM or container images reproducible so that no one needs to trust my build environment. This way, multiple employees or customers could rebuild the image and can be certain that the image corresponds to the specification and CM code. Refer to Security challenges for the Qubes build process.

But at the same time I realize that it will require a lot of work and am not proposing to do that right now. Also because this is probably a not very common usage of the project.

Plus this is currently a future criterion which is SUGGESTED so we don’t lose anything here in terms of getting the badge.