Feature #556
apt provider should support --allow-unauthenticated option
| Status: | Duplicate | Start date: | ||
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Luke Kanies |
% Done: | 0% |
|
| Category: | Debian | |||
| Target version: | - | |||
| Affected Puppet version: | 0.24.4 | Branch: | ||
| Keywords: | ||||
| Votes: | 0 |
Description
with new style apt on etch there are lots of packages which cannot be authenticated. therefore depending on such package fails. it would be nice to have a configuration option for the apt provider to add —allow-unauthenticated to the aptcmd. probably enable this by default.
Related issues
History
Updated by Tim Stoop about 5 years ago
Good idea that the option should be there. I think Luke recently implemented something that allows specific options for providers.
But please, you really don’t want “—allow-unauthenticated” by default…
Updated by Blake Barnett about 5 years ago
Agreed, it should never be the default. APT keys are published and it’s trivial to write an Execget-apt-keys that the package type can be made to depend on.
Updated by Blake Barnett about 5 years ago
Make that
Exec[[get-apt-keys]]
Updated by David Schmitt about 5 years ago
Or install a up-to-date version of debian-archive-keyring. And/or sign local repositories.
Forcing apt to —allow-unauthenticated should not be encouraged because apt has no other safe-guard against package forgery.
Updated by Luke Kanies about 4 years ago
This is dependent on #915.
Updated by Redmine Admin almost 4 years ago
- Status changed from 1 to Needs Decision
Updated by Luke Kanies over 3 years ago
- Status changed from Needs Decision to Rejected
- Affected Puppet version set to 0.24.4
I think at this point this ticket doesn’t make sense. It’s relatively bad management practice — you should be running your own local repository anyway — and we can’t do it until #915 is done.
Updated by James Turnbull about 1 year ago
- Status changed from Rejected to Duplicate