| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
This also catches some recent-ish changes to aes, chacha, and rosc_entropy.
|
|
|
|
|
|
|
|
|
|
This is the recent stuff that's not specific to the fmc_clk effort.
In theory this should all just work (with the old asynchronous
clocking), in practice, well, that's part of what we want to test.
|
|
Some recent changes to sw/libhal were not tested properly against
sw/pkcs11, which led to a couple of build issues and a segfault.
These have now been fixed.
The floggings will continue until morale improves.
|
|
|
|
|
|
Specific reason for this build was to test removal of a couple of
TerASIC-specific files.
Other accumulated changes include:
* A bunch of work on the AES core;
* A bunch of minor performance enhancements in the C code, mostly
related to RSA signature time (which is still a problem, but this
set of fixes removed a bunch of dumb stuff which was masking what we
now think is the root cause of the performance issue);
* A bunch of minor fixes and cleanups in the C code (eg, assertions
now log something to the console rather than just locking up).
|
|
|
|
reprepro strictly follows the Debian package rule that two package
files which have the same name must have identical content. Which is
fine, except when we want to support the same version of a package on
multiple releases of the same Debian-flavored operating system.
The usual hack for this is to add a release-specific tag to the end of
the version string. The brute force way of doing this requires
modifying the source package for each release, but there's an obscure
hack which lets us augment the binary package versions directly.
|
|
NB: this change is not by itself enough to prep the build environment
for new platforms, one must also (manually):
a) Update the conf/distributions files in the reprepro repositories to
include the new codenames;
b) Install an updated version of the debootstrap package on the build
machine so that it knows how to construct the base environment for
the new codenames; and
c) Create the initial pbuilder environments fot the new codenames
using `pbuilder-dist create`.
There may be other steps I've forgotten, it's been a while since we
last added a new codename.
Per recommendation in the Debian Wiki, the debootstrap package I
expect to use for this was manually backported (so that our existing
build machine can know how to build for codenames newer than what the
build machine itself is running). In this case I'm using the
stretch-backports version (to get Ubuntu Bionic).
|
|
|
|
|
|
|
|
Most recent AES core doesn't synthesize properly with core_selector,
and we have other fixes to test. So back AES changes out of the
releng build for now, re-add them when we sort this out.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We don't really need PyCrypto for most things, and installing it on
the fly is easy with apt-get, but it's not worth trying to explain why
it's always included on OSX and has to be installed manually on Linux.
|
|
Python package dependencies in Homebrew packages are tricky enough
that it's easiest just to install PyCrypto unconditionally on OSX.
|
|
|
|
|
|
The ks9 branch of sw/libhal breaks keystore backwards compatability
again. Unclear whether we should do something about that, but since
we do have a workaround in the form of cryptech_backup --soft-backup,
we should ship that *before* we break the keystore again, so that
careful users can back up before the problematic firmware upgrade.
|
|
|
|
Homebrew reserves the right to decide on the fly which copy of the
Python 2.7 interpreter (Apple's or Homebrew's) we should be using.
This is mostly reasonable, but makes it tricky when a Homebrew package
includes both a Python "application" and Python "bindings", because
the bindings may be installed where the script doesn't see them. So
we symlink the bindings into the application's private library tree,
just as if the bindings were a third-party library our application
needed. Silly, but it works (this week).
|
|
|
|
|
|
|
|
|
|
|
|
scripts/build-*.py were treating --conflicts as a sequence of
arguments while Makefile was treating as a single argument whose value
might contain whitespace. No big deal either way for the scripts, and
Makefile is complicated enough, so go with Makefile's approach.
Add some pedantic quoting to Makefile while we're at this, out of
general paranoia and because the inconsistencies were puzzling.
|
|
|
|
|
|
|
|
|
