Hi Sascha,
On 2025-11-04 11:11, Sascha Hauer wrote:
On Mon, Nov 03, 2025 at 12:41:14PM +0100, Jonas Rebmann wrote:
Hi Sascha,
On 2025-11-03 11:08, Sascha Hauer wrote:
On Tue, Oct 28, 2025 at 07:03:20PM +0100, Jonas Rebmann wrote:
Merge the exemplary keys copied in from [1] into a single pem file,
in a manner similar to test/self/development_rsa2048.pem for consistency
and to reduce clutter a bit.
While at it, rename them from "fit-" to "snakeoil-" as they are not only
used for fit, but also for tlv integration tests, and to indicate more
clearly that these are publicly known keys.
Should we rather keep the "fit" name and add another key for tlv
integration tests?
I'd rather not add more 'compromised' keys to the repo. What would be
the gain?
My thinking was that with this we could make sure that during tests
actually a key from the desired keyring is used.
>> I think naming it snakeoil gives it the warning it deserves. We should
make it hard for anyone to confuse our CI/Development keys with their
production keys.
Indeed. I just don't like the term "snakeoil" here.
From wikipedia:
"Snake oil" is a term used to describe deceptive marketing, health care fraud,
or a scam.
We don't do anything like this here. We're not trying to sell snake oil.
I am open for something like "testing" or "development".
I thought this to be a conventional name specifically for keypairs
shipped with software like the debian packages qemu-efi-aarch64 and
ovmf:
https://packages.debian.org/search?searchon=contents&keywords=snakeoil&mode=filename&suite=stable&arch=any
The ssl-cert debian package runs make-ssl-cert generate-default-snakeoil
in its postinst script:
Invoked with "generate-default-snakeoil", it will generate
/etc/ssl/certs/ssl-cert-snakeoil.pem and /etc/ssl/private/ssl-cert-
snakeoil.key.
Other packages do similar things.
I understand "snakeoil" in this context as: 'It may look like it heals
your confidentiality and integrity pains but will be greatly ineffective
for this, don't be deceived!'
Also we might want to add a runtime message like:
"WARNING: This barebox binary contains well known keys and is unsecure"
This is a good idea and I'd also suggest in the future to write pytest
fixtures that let us generate testing key material on the fly. It seems
like a task for a different day so would you be ok with leaving it as-is
for now?
Regards,
Jonas
--
Pengutronix e.K. | Jonas Rebmann |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
