Hi,

Thanks for your reply!

> I know. Having options is good though.

I don't mean to suggest removing these options. I'm arguing it would be
useful, from a security POV, to support env vars in addition.

> Environment vars can also leak to history, if you set them interactively
on the command line.

Yes, anything can leak to history -- but by their nature command line
arguments are particularly vulnerable.

> I wouldn't mind these. ^ It should be pretty simple to implement if you
want to try.

I wish I could easily, but I wouldn't hold your breath necessarily: my C is
shit. :-) I recognize you aren't getting paid for this; just hoping I can
offer a persuasive rationale for you to consider implementing it.

> Proper solution would be to use some credentials agent, though.

I completely agree but I thought that would be too much to ask.

> The most secure option megatool has for passing credentials is that it
will ask for the password interactively if you don't specify it.

Absolutely. But non-interactive scripted operation is important for my use
case.

--
Regards,
Ryan Delaney
ryan.delaney@gmail.com


On Tue, Jan 7, 2020 at 7:09 PM Ondřej Jirman <megatools@megous.com> wrote:

> Hi,
>
> On Tue, Jan 07, 2020 at 06:43:56PM -0800, Ryan Delaney wrote:
> > Hello,
> >
> > Reading secrets from environment variables is generally safer than
> reading
> > them from plain text files on disk. Reading secrets from command-line
> > arguments is also contraindicated because:
>
> I know. Having options is good though.
>
> > 1. It is likely to be stored in the shell history
>
> Environment vars can also leak to history, if you set them interactively
> on the command line.
>
> > 2. It is certain that all arguments are leaked to the process table
> > <https://www.netmeister.org/blog/passing-passwords.html>
>
> Right.
>
> > Also, allowing configuration options to be set with environment variables
> > would enable convenient integration with direnv <https://direnv.net> for
> > using per-directory settings.
> >
> > Possible options might include:
> >
> > MEGA_CONFIG_FILE Path to read the megarc from. All other configs ignored.
> > MEGA_USERNAME
> > MEGA_PASSWORD
>
> I wouldn't mind these. ^ It should be pretty simple to implement
> if you want to try.
>
> Proper solution would be to use some credentials agent, though. Since
> even with env vars you'll typically have those stored somewhere - in the
> script, in shell init file, set the interactively, etc. And it's all
> prone to leaking via rogue same-uid process. So in the end it's at the
> same level as putting password to megarc file.
>
> The most secure option megatool has for passing credentials is that it
> will ask
> for the password interactively if you don't specify it.
>
> > MEGA_SPEED_LIMIT Set both the upload and download speed limits
> > MEGA_DOWNLOAD_LIMIT Override other settings for the download speed limit
> > MEGA_UPLOAD_LIMIT Override other settings for the download speed limit
> > MEGA_CREATE_PREVIEWS If set, create previews
> > MEGA_NOCREATE_PREVIEWS If set, do not create previews
> > MEGA_PROXY Proxy URL, e.g. for SOCKS/tor etc
> > MEGA_CACHE_TIMEOUT Cache timeout in seconds (default: 6000)
>
> But I wouldn't like overdoing it with the rest. ^ :)
>
> regards,
>         o.
>
> > Etc.
> > --
> > Regards,
> > Ryan Delaney
> > ryan.delaney@gmail.com
>