Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: roadmap 2022 thoughts? (.netrc)
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
Date: Sun, 9 Jan 2022 06:44:10 -0500
On 09-Jan-22 05:53, Morten Kjærulff via curl-users wrote:
> On Sat, Jan 8, 2022, 22:25 Daniel Stenberg wrote:
>
> You mean once per invoke and not once per transfer ?
>
>
> Once per invoke. With this i could:
>
> curl -n --netrc-file <(command to display netrc from a very secret place)
>
> The command could be gpg. I guess it would be a bit better that netrc
> in plain text.
.netrc could be read into memory once (of course that might put entries
not used by the current command into the swapfile, in addition to
/dev/mem), or the command line could be pre-scanned for URL references
(including indirect references in files - which other people might want
to pipe in). So prescanning is non-trivial.
But your "very secret place" is hard to keep secret. Your command will
show up in ps (via /proc). Yes, it's hidden from some users - if the
opposition isn't privileged and you trust the filesystem permissions.
If your command comes from a file containing the secret location, you're
counting on file system permissions to protect it. Same if your secret
decryption key is in your gpg keyring - which is a well known and much
more appealing target.
At some point you have to use and trust the filesystem's permissions...
If you're very concerned, your only real option is to reduce the
exposure window by keeping sensitive data on a physically removable
device (e.g. a USB key or CD), physically removing and securing it each
time its used. And perhaps using a multi-part encryption key. (See the
DNSSEC root signing key ceremony -
https://www.internetsociety.org/blog/2015/11/my-view-of-the-dnssec-root-key-signing-ceremony/)
If you do that for your decryption key, you can do it for .netrc too.
A simpler approach to your scheme is to invoke cURL once per URL (and
don't include URLs in indirect files)...which takes no changes to cURL.
The caveats above apply.
>
> On Sat, Jan 8, 2022, 22:25 Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Fri, 7 Jan 2022, Morten Kjærulff via curl-users wrote:
>
> > Read .netrc only once.
>
> You mean once per invoke and not once per transfer ?
>
> It should certainly be doable but I'm not sure it is worth
> spending a lot of
> cycles on it. Home come you think it is an issue in the first place?
>
> --
>
> / daniel.haxx.se <http://daniel.haxx.se>
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html
>
>
Received on 2022-01-09
Date: Sun, 9 Jan 2022 06:44:10 -0500
On 09-Jan-22 05:53, Morten Kjærulff via curl-users wrote:
> On Sat, Jan 8, 2022, 22:25 Daniel Stenberg wrote:
>
> You mean once per invoke and not once per transfer ?
>
>
> Once per invoke. With this i could:
>
> curl -n --netrc-file <(command to display netrc from a very secret place)
>
> The command could be gpg. I guess it would be a bit better that netrc
> in plain text.
.netrc could be read into memory once (of course that might put entries
not used by the current command into the swapfile, in addition to
/dev/mem), or the command line could be pre-scanned for URL references
(including indirect references in files - which other people might want
to pipe in). So prescanning is non-trivial.
But your "very secret place" is hard to keep secret. Your command will
show up in ps (via /proc). Yes, it's hidden from some users - if the
opposition isn't privileged and you trust the filesystem permissions.
If your command comes from a file containing the secret location, you're
counting on file system permissions to protect it. Same if your secret
decryption key is in your gpg keyring - which is a well known and much
more appealing target.
At some point you have to use and trust the filesystem's permissions...
If you're very concerned, your only real option is to reduce the
exposure window by keeping sensitive data on a physically removable
device (e.g. a USB key or CD), physically removing and securing it each
time its used. And perhaps using a multi-part encryption key. (See the
DNSSEC root signing key ceremony -
https://www.internetsociety.org/blog/2015/11/my-view-of-the-dnssec-root-key-signing-ceremony/)
If you do that for your decryption key, you can do it for .netrc too.
A simpler approach to your scheme is to invoke cURL once per URL (and
don't include URLs in indirect files)...which takes no changes to cURL.
The caveats above apply.
>
> On Sat, Jan 8, 2022, 22:25 Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Fri, 7 Jan 2022, Morten Kjærulff via curl-users wrote:
>
> > Read .netrc only once.
>
> You mean once per invoke and not once per transfer ?
>
> It should certainly be doable but I'm not sure it is worth
> spending a lot of
> cycles on it. Home come you think it is an issue in the first place?
>
> --
>
> / daniel.haxx.se <http://daniel.haxx.se>
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html
>
>
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-users Etiquette: https://curl.haxx.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature