| Summary | gpg keys pair |
| Queue | IMP |
| Queue Version | 4.2 |
| Type | Bug |
| State | Not A Bug |
| Priority | 1. Low |
| Owners | |
| Requester | kkkrrruuulll (at) yahoo (dot) it |
| Created | 6/9/08 (6514 days ago) |
| Due | |
| Updated | 6/10/08 (6513 days ago) |
| Assigned | |
| Resolved | 6/9/08 (6514 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
powers is likely opening up a *way* bigger security hole than any
security shortcomings you are trying to mask.
"crack" a db that a process ran with sudo
parameter --homedir (which value can be saved on user's preferences)
public/private keys and his keyrings already full
powers is likely opening up a *way* bigger security hole than any
security shortcomings you are trying to mask.
"crack" a db that a process ran with sudo
server running Horde. Not to mention that a web process having sudo
powers is likely opening up a *way* bigger security hole than any
security shortcomings you are trying to mask.
the private/hidden directory .gnupg of every user; horde/imp must use
gnupg command line (sudo'ed as spamassassin) for every operation
if you run gnugp sudo'ed with the logged user, i think it can access
the user's home
Priority ⇒ 1. Low
State ⇒ Not A Bug
the private/hidden directory .gnupg of every user; horde/imp must use
gnupg command line (sudo'ed as spamassassin) for every operation
Priority ⇒ 3. High
Type ⇒ Bug
Summary ⇒ gpg keys pair
Queue ⇒ IMP
Milestone ⇒
Patch ⇒ No
State ⇒ Unconfirmed
i think that horde/imp must use keys (and keyrings) contained into the
private/hidden directory .gnupg of every user; horde/imp must use
gnupg command line (sudo'ed as spamassassin) for every operation