Hello,
I'm trying to setup (well, actually update to 3.12) my private
repository for alpine packages and I'm facing issues with how to protect
repository signing key from rogue software.
For example, if some shady code is executed as part of a Makefile or
something, it does by default have read access to repository private key
(and it can therefore extract it). I would like to prevent that.
In 3.11, I was using fake dummy key in the build container,
abuild-gzsplit and abuild-sign with the real key which worked fairly
well. However, that is not possible in 3.12 since abuild-gzsplit is
broken there.
How is this issue usually solved? What approach does official Alpine
repository takes? What approach do people with private repositories use?
Thanks in advance :)
W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
> On Jun 13, 2020, at 4:24 PM, Wolf <wolf@wolfsden.cz> wrote:> > Hello,> > I'm trying to setup (well, actually update to 3.12) my private> repository for alpine packages and I'm facing issues with how to protect> repository signing key from rogue software.> > For example, if some shady code is executed as part of a Makefile or> something, it does by default have read access to repository private key> (and it can therefore extract it). I would like to prevent that.> > In 3.11, I was using fake dummy key in the build container,> abuild-gzsplit and abuild-sign with the real key which worked fairly> well. However, that is not possible in 3.12 since abuild-gzsplit is> broken there.
This is something I have spent considerable time thinking about and the strategy you describe is basically what I have encoded in software that I've been developing called APK Foundry. It's basically abuild's rootbld feature built out to support Gitlab CI and has some nice features like being able to easily reuse containers that rootbld doesn't really support. It generates a throwaway key inside the container and can re-sign packages outside of the container using the precious key for you. It's still a work in progress but it should be mostly usable out of the box for local building, just needs some documentation on how to get started quickly.
It sounds like abuild-gzsplit needs to be fixed then; you should file an issue on alpine/abuild.git.
> How is this issue usually solved? What approach does official Alpine> repository takes? What approach do people with private repositories use?
I can't speak for Alpine but Adélie doesn't have mitigations for this in place yet; it is my hope that we will eventually adopt my software to fix that. As far as I know most developers with private repositories use either lxc/lxd, docker-abuild, or just build directly on the host (eww) and don't really consider these issues.
Max
On 2020-06-13 16:52:42 -0500, Maxwell Rees wrote:
> [..]> the strategy you describe is basically what I have encoded in software> that I've been developing called APK Foundry.> [..]
Is that somewhere available so that I can take a peek? Searching for
`APK Foundry' gave be bunch of android-related pages.
> It sounds like abuild-gzsplit needs to be fixed then; you should file> an issue on alpine/abuild.git.
I've done that already [0] :) . The issue is that abuild-gzsplit
explicitly checks for names of entries [1], which broke when they were
switched to use PaxHeaders in 660f793d6de6291204ba044e03b37826d2e78e88
[2]. Sadly I do not have enough knowledge to be confident enough to put
forward a patch for this.
[0] https://gitlab.alpinelinux.org/alpine/abuild/-/issues/9999
[1] https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild-gzsplit.c#L36
[2] https://gitlab.alpinelinux.org/alpine/abuild/-/commit/660f793d6de6291204ba044e03b37826d2e78e88
As a side note, would you know if there is a reason why abuild does not
have any tests? Like, this would be found by *any* test suite checking
basic functionality. Is it matter of ideology or just no one had time to
write them?
> > How is this issue usually solved? What approach does official Alpine> > repository takes? What approach do people with private repositories use?> > I can't speak for Alpine but Adélie doesn't have mitigations for this> in place yet; it is my hope that we will eventually adopt my software> to fix that. As far as I know most developers with private> repositories use either lxc/lxd, docker-abuild, or just build directly> on the host (eww) and don't really consider these issues.
That's... sad state of things. I will probably end-up with patched
abuild that will just not call abuild-sign as a temporary workaround.
Do you think it would be useful to actually have such a flag as an
option (== should I try to do it in proper way and upstream it)?
W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
On Sun Jun 14 01:06 AM, Wolf wrote:
> Is that somewhere available so that I can take a peek? Searching for> `APK Foundry' gave be bunch of android-related pages.https://code.foxkit.us/sroracle/apkfoundry
It is still a work in progress; notably it requires a patched abuild so
that it can interpose some privileged functionality and allow for
building packages outside of the aports git repository. I haven't gotten
around to upstreaming those patches yet, but they can be found on this
branch:
https://code.foxkit.us/adelie/abuild/commits/apkfoundry
Additionally for Alpine it requires a copy of bwrap that runs without
the setuid bit set on the binary. We have such a copy packaged for
Adélie but I don't think Alpine has one; you could probably just make
your own.
Once you have those components in place you should be able to run "make
quickstart", adjust your PYTHONPATH and PATH, and start working with it.
I really want to document this all as a "quick start" guide, just
starved for time at the moment. As a reference until that documentation
is complete, this is the configuration I've been using with it:
https://code.foxkit.us/sroracle/af-config
You just drop that as an .apkfoundry folder in the root of your
aports.git clone. Would need some adjusting as well for Alpine of course
:)
> I've done that already [0] :) . The issue is that abuild-gzsplit> explicitly checks for names of entries [1], which broke when they were> switched to use PaxHeaders in 660f793d6de6291204ba044e03b37826d2e78e88> [2]. Sadly I do not have enough knowledge to be confident enough to put> forward a patch for this.> > [0] https://gitlab.alpinelinux.org/alpine/abuild/-/issues/9999> [1] https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild-gzsplit.c#L36> [2] https://gitlab.alpinelinux.org/alpine/abuild/-/commit/660f793d6de6291204ba044e03b37826d2e78e88
As I just mentioned in the issue, Adélie has been using PAX format apks
for a while now and I had to fix this very issue; I will send the patch
for it upstream. It's already integrated into Adélie's abuild.
> As a side note, would you know if there is a reason why abuild does not> have any tests? Like, this would be found by *any* test suite checking> basic functionality. Is it matter of ideology or just no one had time to> write them?
Adélie has a rudimentary test suite for abuild and newapkbuild (but not
any of the other utilities notably):
https://code.foxkit.us/adelie/abuild/-/tree/master/tests
I think this was submitted as a PR to upstream when it was still on
GitHub but it was never merged. I think it is mostly due to lack of time
to work on it, not ideology.
When I was working on a Python implementation of abuild, I wrote an even
more extensive test suite for it:
https://code.foxkit.us/sroracle/py3-abuild/-/tree/master/tests
However that project is on hold for now.
> That's... sad state of things. I will probably end-up with patched> abuild that will just not call abuild-sign as a temporary workaround.> > Do you think it would be useful to actually have such a flag as an> option (== should I try to do it in proper way and upstream it)?
This is an interesting idea. I would have to think more about what the
pro/cons are of signing after each build instead of re-signing it all at
the end, but it seems worthwhile to me off the top of my head.
Max