Bug#589991: mime-support: MIME types needed for x-gzip and x-compress

2010-09-01 Thread Derek Martin
On Wed, Sep 01, 2010 at 03:11:15PM +0200, Brian White wrote: > > > As you say, purpose matters. There is no purpose to data just > > > because it's gzipped. > > > > False. The purpose is to take up less space. > > > > That's why you compressed it. Yes, exactly; that's its purpose. > That's

Bug#589991: mime-support: MIME types needed for x-gzip and x-compress

2010-08-30 Thread Derek Martin
On Mon, Aug 30, 2010 at 03:16:08PM +0200, Brian White wrote: > > Everything is an encoding. HTML is an encoding. MP3 is an encoding. > > ASCII is an encoding. All digital data on a computer is an encoding > > of some sort. Purpose *absolutely* matters. > > > > All of those are more than an enc

Bug#589991: mime-support: MIME types needed for x-gzip and x-compress

2010-08-19 Thread Derek Martin
On Thu, Aug 19, 2010 at 08:24:22PM +0200, Brian White wrote: > > But I don't see why adding these MIME types -- which many other OSes > > do include in their system-wide mime.types file, including many other > > Linux distros -- should break Apache. > > Because if .gz was present, it would send th

Bug#589991: mime-support: MIME types needed for x-gzip and x-compress

2010-08-19 Thread Derek Martin
On Wed, Aug 18, 2010 at 11:38:42AM +0200, Brian White wrote: > > I will systematically prove that (depending on semantics) either this > > is outright false, or that the term "encoding" has been > > misappropriated and, in the context of MIME, excluding these on the > > basis that they are "encodin

Bug#589991: mime-support: MIME types needed for x-gzip and x-compress

2010-07-22 Thread Derek Martin
Package: mime-support Version: 3.48-1 The mime.types file is missing MIME types for x-gzip and x-compress. The debian mime.types file states: # Note: Compression schemes like "gzip", "bzip", and "compress" are # not actually "mime-types". They are "encodings" and hence must # _not_ have entri

Bug#96144: mutt/580: mutt stores PGP passphrase insecurely

2005-10-09 Thread Derek Martin
The following reply was made to PR mutt/580; it has been noted by GNATS. From: Derek Martin <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], Mutt Developers <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mutt/580: mutt stores PGP passphrase insecurely Date: Sun

Bug#96144: mutt/580: mutt stores PGP passphrase insecurely

2005-10-09 Thread Derek Martin
On Fri, Oct 07, 2005 at 02:42:51PM +0200, Thomas Roessler wrote: > On 2005-10-07 04:35:02 +0200, Derek Martin wrote: > > > Er, well, come on... just because Mutt *can* use an auxiliary > > program to handle encryption passphrases securely doesn't mean > > mutt it

Bug#96144: mutt/580: mutt stores PGP passphrase insecurely

2005-10-06 Thread Derek Martin
The following reply was made to PR mutt/580; it has been noted by GNATS. From: Derek Martin <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Mutt Developers <[EMAIL PROTECTED]>, "Marco d'Itri" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: mutt/580: mutt stor

Bug#96144: mutt/580: mutt stores PGP passphrase insecurely

2005-10-06 Thread Derek Martin
On Wed, Oct 05, 2005 at 05:55:17AM +0200, Brendan Cully wrote: > Synopsis: mutt stores PGP passphrase insecurely > State-Changed-From-To: open->closed > State-Changed-Why: > Mutt can use gpg-agent, which pushes this problem outside of mutt's domain. Er, well, come on... just because Mutt *can* us

Bug#128945: mutt/973: encrypt mail with more keys than recipient list (think mailinglist)

2005-10-04 Thread Derek Martin
On Tue, Oct 04, 2005 at 07:05:00PM +0200, Rado Smiljanic wrote: > Synopsis: encrypt mail with more keys than recipient list (think mailinglist) I happen to agree that mutt should have a facility to select recipient encryption keys independent of the message recipients; however as a work-around yo