[Cryptech Core] Alpha firmware packaging

[Basil Dolmatov]

All this is reasonable. 
The only doubt I have coming from my experience of incompatibility between different Python versions (even if only minor number changes). I doubt that Python will stop increase its version numbers and I equally doubt that Python developers would changed their attitude.
So, thing I feel necessary, while going this way: to find simple (for the user) procedure to detect this problem and to give him the tool to easily fix it. 

Отправлено с iPhone

> 18 июня 2016 г., в 4:37, Rob Austein <sra at hactrn.net> написал(а):
> 
> Brief call for objections.
> 
> On the Novena, everything was Debian, so there was an obvious
> packaging mechanism to use for all the binaries.  That's not really
> the case for the Alpha.
> 
> For the Alpha, ignoring a lot of messy internals of how we build
> stuff, there are basically two kinds of binary packages:
> 
> * A firmware package, containing an FPGA bitstream and images of the
>  software running on the HSM's CPU (probably both .elf and .bin
>  format to support both ST-LINK and DFU without requiring objcopy,
>  possibly also including bootloader images); and
> 
> * A software package, containing stuff that goes the host side
>  (libpkcs11.so, the RPC daemon, whatever).
> 
> For a given revision of the source code, there's only one firmware
> package, but there may be a lot of software packages (OS, CPU
> architecture, etc).  I am skipping slightly over a lot of nasty
> details of the build system here, because this message is about the
> result from the user's standpoint, not the system that produces it.
> 
> The host side software package should use whatever packaging makes
> sense for that platform: .deb, Homebrew, whatever.  On most platforms
> we're likely to support there's an obvious format, we just use it.
> 
> There isn't really any single obvious format for the firmware package.
> Requiring a separate firmware package for each host system seems
> wrong, as does the degenerate case of only allowing firmware upgrades
> from Debian-family systems, so I don't really want to tie the firmware
> packaging to any particular platform's native packaging system.
> 
> Most of our upload software is already Python, and the bits that
> aren't yet (the stuff for uploading via an ST-LINK) may end also end
> up using Python (right now it's a shell script, but the maze of
> configuration possibilities for openocd (multiple operating systems,
> multiple openocd releases, multiple st-link programmer models) is
> starting to get out of hand, and it would probably be simpler to sort
> this out in Python than in a shell script).  So I'm thinking that the
> simplest thing here would just be to use a boring archive format that
> Python already supports out of the box.  Therefore, my current plan is
> to package the firmware binaries in a plain old compressed tarball.
> 
> Whether to include the scripts necessary to use the firmware package
> in the base software package or put those in a separate developer's
> package is an open question: I might just put them all in one package
> for now for simplicity, but I don't feel strongly about it.  Whichever
> software package includes scripts for dealing with the firmware would
> also have the runtime dependency hooks to pull in whatever external
> packages we need to use the firmware tarball (eg, openocd).
> 
> The firmware tarball should probably also contain a signed manifest: a
> text file listing names and SHA-256 digests of the other content of
> the tarfile, signed by the same PGP key that signs the APT repository,
> commits to the Homebrew repository, etc.  There are other ways to
> slice this, but I think a single signed manifest is simplest overall.
> 
> The firmware tarball may also contain a bit of additional meta-data in
> whatever format seems simplest (read: encoded in some boring format
> that Python can read out of the box, eg, JSON), but that's basically
> it.  The signed manifest and the meta-data might end up being the same
> file, or not, details to be worked out.
> 
> If anybody strenuously objects to this plan, holler, soon.
> _______________________________________________
> Core mailing list
> Core at cryptech.is
> https://lists.cryptech.is/listinfo/core