$TMPDIR (was Re: Security: Mutt and mailcap rules)
On Sun, Jun 23, 2019 at 12:36:07PM +0200, Vincent Lefevre wrote: > On 2019-06-23 14:44:36 +1000, Cameron Simpson wrote: > > Were it a simple filename it would all be easy. Maybe a chdir(tmpdir) > > before running the shell command with a simple filename? > > I'm not sure whether this is a good idea. The temporary directory > may be (and often is) world-writable, and on multi-user machines, > this increases the risk of vulnerability. For instance, some > programs may consider configuration files in the current working > directory, and/or may write/re-read files there. While I don't disagree with anything you said, FWIW: $ echo $TMPDIR /home/dmartin/tmp $ ls -ld $TMPDIR drwx-- 9 dmartin users 4096 Jun 24 16:45 /home/dmartin/tmp/ Mutt honors $TMPDIR. You should set it. You should probably not use /tmp, especially on a multi-user system, especially if you care about security (privacy to be more precise, but that's part of security). You should probably also not put it on NFS. For that matter, you should probably not put anything sensitive on NFS, which likely includes your mail (and there are other reasons to avoid that as well). This (or something akin to it) used to be (at least in my circles) somewhat common knowledge/practice, but it seems the young'ns don't learn such things anymore. Sadly plenty of more recent POSIX-ish software programs don't know or don't care about $TMPDIR or other such historical features anymore. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpcSlGUyIEND.pgp Description: PGP signature
Re: $TMPDIR (was Re: Security: Mutt and mailcap rules)
Derek Martin wrote in <20190624221827.ga13...@bladeshadow.org>: |On Sun, Jun 23, 2019 at 12:36:07PM +0200, Vincent Lefevre wrote: |> On 2019-06-23 14:44:36 +1000, Cameron Simpson wrote: |>> Were it a simple filename it would all be easy. Maybe a chdir(tmpdir) |>> before running the shell command with a simple filename? |> |> I'm not sure whether this is a good idea. The temporary directory |> may be (and often is) world-writable, and on multi-user machines, |> this increases the risk of vulnerability. For instance, some |> programs may consider configuration files in the current working |> directory, and/or may write/re-read files there. | |While I don't disagree with anything you said, FWIW: | |$ echo $TMPDIR |/home/dmartin/tmp |$ ls -ld $TMPDIR |drwx-- 9 dmartin users 4096 Jun 24 16:45 /home/dmartin/tmp/ | |Mutt honors $TMPDIR. You should set it. You should probably not use |/tmp, especially on a multi-user system, especially if you care about |security (privacy to be more precise, but that's part of security). |You should probably also not put it on NFS. For that matter, you |should probably not put anything sensitive on NFS, which likely |includes your mail (and there are other reasons to avoid that as |well). | |This (or something akin to it) used to be (at least in my circles) |somewhat common knowledge/practice, but it seems the young'ns don't |learn such things anymore. Sadly plenty of more recent POSIX-ish |software programs don't know or don't care about $TMPDIR or other such |historical features anymore. Hmm, while i totally support the $TMPDIR environment variable, and personally dislike it a lot if i set it and someone simply does not adhere to it, and if its only for testing purposes.., it shall be remarked that OpenBSD "removed support for $TMPDIR" in the base system, as far as i know and recall. Are they young? Well, yes.. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: $TMPDIR (was Re: Security: Mutt and mailcap rules)
On Tue, Jun 25, 2019 at 12:45:02AM +0200, Steffen Nurpmeso wrote:
> Hmm, while i totally support the $TMPDIR environment variable, and
> personally dislike it a lot if i set it and someone simply does
> not adhere to it, and if its only for testing purposes.., it shall
> be remarked that OpenBSD "removed support for $TMPDIR" in the base
> system, as far as i know and recall. Are they young? Well, yes..
I think you must be mistaken, because A) that would be insane, B)
would require a lot of pointless work to remove it from many shell
utilities (and all of the shells), and C) I see references to it
being supported, for example in ssh and ssh-agent, the mktemp man
page, the ksh (openbsd's default shell) man page, etc..
I did see reference to support for $TMPDIR being removed from crontab
("because it's not useful in crontab"), which seems kind of idiotic to
me, as well as sendbug and newfs (why would newfs need $TMPDIR anyway?
Though it seems useful in sendbug)... but that does not amount to it
being removed from the core system.
That said, none of it matters in the context of Mutt, unless they went
out of their way to remove support for it in their port... but even
then you can always just get the source.
--
Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgp7V9PrC9t_Z.pgp
Description: PGP signature
Re: meaning of number of lines in the message (%l in index_format)
On Sat, Jun 22, 2019 at 10:47:42PM +0200, Vincent Lefevre wrote: > The manual says: > > %l number of lines in the message > (does not work with maildir, mh, > and possibly IMAP folders) > > I think that it should emphasize on the fact that this is the number > of lines in the encoded message. For instance, 8bit and base64 can > give significantly different results (unfortunately some mail software > uses base64 even when 8bit would be sufficient, and this is what > happens with some GNU mailing-list, where the users' messages are > re-encoded in base64). Moreover, one does not have an indication on > what encodings are used. > > I think that the manual should say more about these issues. > Perhaps discourage this sequence? Or just remove it. If it's not accurate (or even if it is) what value can it really provide? Even when it *is* accurate the number of lines the user sees depends on how they're formatted, which also depends on things like display filters, etc. [I'm on a kick lately to remove old code of questionable value, in the name of reducing complexity and future maintenance cost, so... =8^)] -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpmEXAe_dysc.pgp Description: PGP signature
Re: meaning of number of lines in the message (%l in index_format)
On Mon, Jun 24, 2019 at 06:41:56PM -0500, Derek Martin wrote: > On Sat, Jun 22, 2019 at 10:47:42PM +0200, Vincent Lefevre wrote: > > I think that the manual should say more about these issues. > > Perhaps discourage this sequence? > > Or just remove it. If it's not accurate (or even if it is) what value > can it really provide? Even when it *is* accurate the number of lines > the user sees depends on how they're formatted, which also depends on > things like display filters, etc. Meant to also mention that it makes mailbox parsing slower, though the user *may* not be likely to notice depending on the details of their usage paterns and system resources. It does not seem (to me) likely that the info would be used in any sort of decision about whether to read a particular message or what to do with it. Anyway, I know it won't be removed, but there's my $0.002. :) -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgppDKuaTqyBL.pgp Description: PGP signature
Re: potentially incorrect conversion of pointer to unsigned long
On Sat, Jun 22, 2019 at 07:19:41AM -0700, Kevin J. McCarthy wrote: On Sat, Jun 22, 2019 at 09:42:36AM +0200, Vincent Lefevre wrote: IMHO, the best solution for safety would be to use a union (I think that this would require the use of C99 designators for the MuttVars initialization). Okay, I will work on this. I think it's better to fix this the right way now then get bitten by this later. I've pushed up a couple commits to the kevin/muttvar-rework branch. If there are no objections, I will continue the same basic work with the Commands[] array too. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
