Testing and Automation

How (not) to make a mockery of trust

Testing client software for public-key infrastructure
D.testing
Matthias Valvekens
<p>The ever-continuing push for digitalisation has increased our reliance on trust services of various kinds, filling various needs relating to document signing, code signing, authorization tokens, and so forth. Many of these trust services rely on public-key infrastructure (PKI) and X.509 certificates.</p> <p>The sensitive nature of these tools makes them difficult to use in a testing environment. On the one hand, exposing access to production keys in your CI is obviously a terrible idea. But on the other hand, setting up and maintaining a fully functional "mock" PKI environment is also pretty tricky. What can you do about that?</p>
Using PKI tools in test workflows involves many challenges. Here are a few examples: Even a (supposedly) basic task like validating an X.509 certificate involves quite a bit of complexity. Apart from "local" validation logic, you might also have to check the revocation status of your certificate, which could entail talking to an OCSP responder service or looking up a CRL. If you're using secure timestamps (RFC 3161) in your code, your tests might also require access to a time stamping service. Maybe you're using a remote signing service vendor that doesn't offer any sort of "sandbox" for testing purposes. In all of these scenarios, both test data generation and mock service integration can be quite cumbersome. Both in my own time and on the job, I write a lot of code that relates to digital signing in various ways, and this is a kind of problem that I run into all the time. After trying out a variety of methods, I grew dissatisfied with the "traditional" options, and rolled my own PKI testing framework: Certomancer. Certomancer helps with both test data generation, performs trust service mocking, comes with a plugin API, and most importantly, it's FOSS (MIT licence). In my talk, I'll take you through some of the "how"s and "why"s of Certomancer's feature set, and talk about some of the mileage that I've gotten out of it.

Additional information

Type devroom

More sessions

2/5/22
Testing and Automation
D.testing
<p>A warm welcome from your devroom managers, practical information, lineup and administrivia. Happy Testing!</p>
2/5/22
Testing and Automation
Richard Palethorpe
D.testing
<p>How we use the Sparse C Abstract Syntax Tree and linearized Intermediate Representation to write custom checks for the Linux Test Project API.</p>
2/5/22
Testing and Automation
Laurent Carlier
D.testing
<p>The technical presentation is about how to use mocks to unit test Linux kernel drivers. The presentation explains how mocks help validating operational code. For instance by checking parameters passed to mocked function, or by configuring the mock to return an error code.</p> <p>The presentation will include some unit test examples that use a mocking tool which is called EasyMock. I'm the author of EasyMock.</p>
2/5/22
Testing and Automation
Armand Bénéteau
D.testing
<p>The concerns about code complexity, cybersecurity and LTS have made a continuous testing infrastructure a must have.</p> <p>The tests must take place both in virtual and real target. Virtual target because developers never get enough physical boards to test from, and real in order to limit virtualization/reality deviation.</p>
2/5/22
Testing and Automation
Fotis Nikolaidis
D.testing
<p>As distributed systems evolve, the testing scale multiplies, asking for dozens of test cases, combined with different application benchmarks (e.g., performance, correctness), and arbitrary operating conditions. Kubernetes holds a promise to enable automation and process improvement directly contributing to a system's reliability. Establishing a declarative API and providing a cheap and disposable environment, Kubernetes makes it easy to create uniform experiments, which may run manually or be ...
2/5/22
Testing and Automation
D.testing
<p>Maintaining software systems for a long time is hard. Backporting kernel patches is a complex and expensive overhead. The Linux project's position is - quite rightly - to instruct down-streams to upgrade to the latest release.</p> <p>In practice, upgrading is difficult, scary and sometimes avoided. It takes time and effort before there is enough confidence that new releases will work in context: full system testing in embedded environments can be arduous. What if we could have continuous, ...
2/5/22
Testing and Automation
Stevan Radaković
D.testing
<p>In this session we introduce and explain the integration between LAVA (Linaro Automated Validation Architecture) and GitLab as part of the testing efforts in the Oniro OS from Eclipse foundation. The session will cover brief introductions to LAVA and Oniro, integration with GitLab and also present on how we provide vendors the opportunity to test the full software stack on the live devices in-house in completely integrated manner with the main lab and have the test results available for ...