You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 10, 2022. It is now read-only.
When performing operations such as uploading a package, deb-s3 fetches existing manifest and release files and trusts them fully without verifying that they are signed by a trusted key. This allows for the security provided by apt repository signing to be defeated:
Adversary with ability to write to the bucket but without the signing key uploads a malicious package(s) and updated but unsigned manifest/release files that incorporate the malicious package(s).
When the authorized deb-s3 user (who has the signing key) performs any operation where deb-s3 updates the manifests/release, the malicious package(s) become incorporated into a validly signed release.
The entire point of apt repository signing is to prevent malicious tampering with the repository by an adversary that as a given does have the ability to modify the repository at rest but does not have any trusted signing keys.
By failing to verify that information retrieved from the bucket has not been tampered with before incorporating that information into updated manifest/release files that are signed with a trusted key, deb-s3 creates an opportunity for malicious packages to be distributed as if the adversary had control of a trusted signing key.
The text was updated successfully, but these errors were encountered:
@tomelliff Ideally, that would of course never happen. However, at-rest compromise of package repositories(/mirrors) does happen, that's a part of why the ability for signing to happen offline is a feature of most robust update/distribution schemes.
The issue here is that deb-s3 undermines that by blindly trusting the at-rest repo, treating the signature as just a thing to be done so that clients trust the repo instead of as part of keeping the repo itself secure.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When performing operations such as uploading a package, deb-s3 fetches existing manifest and release files and trusts them fully without verifying that they are signed by a trusted key. This allows for the security provided by apt repository signing to be defeated:
The entire point of apt repository signing is to prevent malicious tampering with the repository by an adversary that as a given does have the ability to modify the repository at rest but does not have any trusted signing keys.
By failing to verify that information retrieved from the bucket has not been tampered with before incorporating that information into updated manifest/release files that are signed with a trusted key, deb-s3 creates an opportunity for malicious packages to be distributed as if the adversary had control of a trusted signing key.
The text was updated successfully, but these errors were encountered: