| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Ubuntu 20.04 no longer really supports Python 2, so we'd have to fork
the packaging code if we wanted to keep support for Python 2
elsewhere. Given that Python 3 has been around for a more than a
decade and that Python 2 was formally EOLed more than six months ago
as of this writing, this seems like an unnecessary complication.
The biggest change is rewriting the Homebrew formula for Python 3.
|
|
This is a first step towards moving all of the Cryptech code from
Python 2 to Python 3. At this stage, the goal is to make the same
source code work in both language dialects, and to build packages
which install both versions of the library code.
This is a necessary step along the way, but since Python 2 is already
past EOL as of this writing and since some distributions have started
dropping all support for Python 2, we will almost certainly want to
drop all Python 2 support in the relatively near future, if only
because it's not really to do all the packaging right for both
versions at once without much more trouble than a dead language
dialect is probably worth. All platforms we care about should support
Python 3 already, any that don't probably have much worse problems.
So the primary purpose of pushing this particular commit is to archive
what will probably be the last version supporting Python 2, while
giving folks a chance to test the incoming Python 3 support a bit.
Once we've cut loose from Python 2 for good, there's some cleanup we
can and should do (eg, all the gymnastics to work around Python 2's
handling of bytes as a form of text rather than a sequence of small
integers), but for the moment we want to keep that compatability,
albeit briefly.
|
|
|
|
It's been a while since we did a full reproducible build via the
releng tree. Some of the old modules are now obsolete, and a couple
of the new ones weren't present.
This is an initial test after updating the existing submodules and
adding the missing ones. I don't really expect it to work, it's a
first attempt.
At minimum, we should go through and clean out submodules we no longer
use, but that can wait until we figure out if we now have all the
right modules and branches recorded here and whether the resulting
configuration works properly.
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Goodbye, CMSIS RTOS, with your interrupt-unsafe mutexes, your priority
inversions, and your thread structure that no debugger understands.
Don't let the door hit you on the way out.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
