| ID: | 4608 |
| From: | rn...@igor2.repo.hu |
| Date: | Tue, 1 Dec 2020 11:48:52 +0100 (CET) |
| Subject: | [pcb-rnd] [dev] autobuild, digital signature |
| replies: | 4609 from ka...@aspodata.se |
Hi all, the new autobuild system is coming slower than expected, because I bumped into hard-to-resolve problems. As a side effect we got a new tool, pusign, which I will describe in this mail. This might be interesting to developers, safe to skip for users. After pondering the overall architecture of the system, I figured I can do almost the same thing for ST and MS if I run everything within the qemu guest (the exotic system we are testing on). So the user needs to start the emulation, the emulated system will go and pick up jobs from the central server and report back. The user's own operating system in which this all is running can be anything that can run qemu - and that's literally anything people run on strong machines these days, from linux to macOSX to windows. We are not going to run much on that system, so we don't need to worry about what the user has installed. Sounds easy, but as usual, some details make it hard. For example, how to do secure communication between our systems. The main worst-case problem to solve is: - you have an old UNIX system, something from the mid 90s, just reached c89 level, doesn't have anything fancy (no GNU) - you want to make secure exchange of files (e.g. the job file from the server, or the report from the autobuild host) There's no https or ssl of any kind, those started to be widespread a decade later even on free systems (and non-free systems are usually lagging behind a bit). There's no ready-to-use tls or ssl lib either. But even if there was, it would be so old that it would be hard to make them communicate to modern systems (like the one that is handing out the jobs). It's like when you install a 15+ years old linux and you can't ssh to anything on your lan because it's trying to use crypto too old for today systems... After thinking these over, the trivial conclusion was: take some small, portable crypto lib and write your own tool! Well, except: it seems nobody is really trying to write small, portable crypto libs. Crypto libs are huge and are optimized for speed at a cost of portability: nobody cares if it would compile on a 15..25 years old system, just make it 0.1% faster on the latest hardware! With the help of Aron, a fellow pcb-rnd user, we managed to build a small tool (~2500 sloc), called pusign (for "portable micro sign"). It tries to do only one thing: sign/verify files using rsa+sha256. And it's c89, without any dependency. You can take a look: svn://svn.repo.hu/autobuild/trunk/common/pusign The RSA code is from bearssl (which is not very close to being portable in the sense we need: uses 64 bit integers in some key APIs, c99 stdint.h, the 'inline' keywordm etc). The sha256 code is from freebsd's WPA tool, which happens to be a bit less PITA to port. The pusign utility code is Aron's work. Now the plan is that the central server will run a web server with cgi; ST and MS autobuild hosts will run a small, custom tool, probably written in C, in a loop: - it will contact the server via http and hand in a job request - if there's anything that needs to be compiled on the given system, the server makes an svn export, packs it up in a tarball and sends it back (svn checkout is not very efficient in transferring files, especially on very slow, emulated system haivng it from a tarball pays off) - the autobuild host does the build using scripts shipped with the system - when it finished, a report is sent back via a http multipart post request (file upload for the build log in case the build failed) All http traffic will be in form of signed request/response files. There's no encrpytion, but that's not a real issue: all data are public, e.g. the job (the source code to compile) or the result of the compilation. The important part is that an attacker, not being able to properly sign files, can not: - send valid job requests to autobuild hosts (the attacker doesn't have the server's private key to sign the request file) - send valid reports to the server about jobs handed out to autobuild hosts (the attacker does not have the private key of the user who is running the autobuild host) Anyway, if you need a small, portable rsa+sha256 digital signature tool or lib, and you are fine with BSD+MIT license, you may find pusign useful for your project. Best regards, Igor2
Reply subtree:
4608 [pcb-rnd] [dev] autobuild, digital signature from rn...@igor2.repo.hu
4609 Re: [pcb-rnd] [dev] autobuild, digital signature from ka...@aspodata.se
4610 Re: [pcb-rnd] [dev] autobuild, digital signature from rn...@igor2.repo.hu