Commit Graph

5 Commits

Author SHA1 Message Date
André Roth 49ff832f94 reenable lost tests 2024-07-24 21:19:47 +02:00
André Roth 440c3debdc improve api tests and error output
show only relevant aptly logs if a test fails.
for async tasks, show task output, as it contains the error message.
2024-07-24 21:19:47 +02:00
Lorenzo Bolla 035d5314b0 Convert tests to Python 3
Fix #938
2022-01-27 15:06:33 +01:00
Andrey Smirnov 2943422d5d Automatic versioning for aptly
New version format:

* for releases, `x.y.z` (follows tag without leading `v`)
* for nightly builds, `x.y.z+N+hash` (previous version, not the upcoming one)

This means that each nightly build `aptly` would report
correct version now.

Version is now complied into the aptly binary, system tests
automatically check for current version, no need to update them
anymore.
2017-03-25 00:18:45 +03:00
Harald Sitter dbee214259 support serving the API over unix domain socket
`unix://$PATH` as listen argument will bind aptly to a unix domain socket
rather than TCP.

This allows binding the API to a UDS rather than a port.
Since aptly has no concept of authentication or any amount of high level
API hardening one needs to bottle it up in some other manner. Binding
to a localhost port is often a step in the right direction, ultimately is
still a scary insecure setup as any user on that host getting compromised
would mean that the entire archive is compromised as well.
UDS on the other hand are basically files and have their access managed
by regular file permission. As such, binding to a socket is in fact
the least insecure way to listen as you'd have to explicitly open up the
socket permissions to an access qualified group. In the most conservative
scenario that means no one but the aptly user can talk to the API, in a
more practical setup apache might get access as well and proxy the UDS
with authentication or limited to GET operations.

Using UDS allows reducing the attack surface of the API server while
preserving all the flexibility.
2017-02-28 09:58:39 +01:00