New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change example for the -F file uploading option #752

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
3 participants
@tbodt
Contributor

tbodt commented Apr 5, 2016

It's a very, very, very bad idea to upload your password file anywhere, especially over http. I know it's just an example, but we certainly don't want anyone copy-pasting it.

Change example for the -F file uploading option
It's a very, very, very bad idea to upload your password file anywhere, especially over http. I know it's just an example, but we certainly don't want anyone copy-pasting it.
@bagder

This comment has been minimized.

Show comment
Hide comment
@bagder

bagder Apr 6, 2016

Member

I'd hold back a bit on the "verys", since the /etc/password file doesn't contain any actual passwords in operating systems shipped during the last 20 years or so. The /etc/shadow that contains the password hashes was introduced in 1987(!).

If a user actually would be tricked by the curl man page to send his/hers actual passwords over HTTP to a remote server, that user won't be saved by this edit.

But okay. For the remote possibility that we someone would encourage silly behaviors with this example I don't mind changing it to something more benign. I would however prefer not to use a dot file and not a vimrc basically since it isn't a known file to many users. I'll instead modify your update to use an image file.

    Example: to send an image to a server, where 'profile' is the name of the
    form-field to which portrait.jpg will be the input:

    curl -F profile=@portrait.jpg https://example.com/upload.cgi

Member

bagder commented Apr 6, 2016

I'd hold back a bit on the "verys", since the /etc/password file doesn't contain any actual passwords in operating systems shipped during the last 20 years or so. The /etc/shadow that contains the password hashes was introduced in 1987(!).

If a user actually would be tricked by the curl man page to send his/hers actual passwords over HTTP to a remote server, that user won't be saved by this edit.

But okay. For the remote possibility that we someone would encourage silly behaviors with this example I don't mind changing it to something more benign. I would however prefer not to use a dot file and not a vimrc basically since it isn't a known file to many users. I'll instead modify your update to use an image file.

    Example: to send an image to a server, where 'profile' is the name of the
    form-field to which portrait.jpg will be the input:

    curl -F profile=@portrait.jpg https://example.com/upload.cgi

@bagder bagder self-assigned this Apr 6, 2016

@bagder bagder closed this in f07cc91 Apr 6, 2016

@deltaray

This comment has been minimized.

Show comment
Hide comment
@deltaray

deltaray Apr 6, 2016

Thanks to both of you. I noticed that mypasswd.com was registered possibly after this example was put into the man pages. I couldn't find the exact date as the repo logs don't go back that far. Had you ever had any encounters with the domain owner Griffin de Luce? Looks like he wasn't a contributor or anything and eventually lost interest in harvesting /etc/passwd files from this example. My guess is that very few people ever really ran this so the problem is minimal. But I'm glad its fixed.

BTW, putting encrypted hashes into /etc/shadow was still an option in some versions of Linux in the late 90s at least. I remember Red Hat Linux had an option for enabling it and the default was not to enable it. So there could have been some password hash leakage, albeit, a long time ago.

deltaray commented Apr 6, 2016

Thanks to both of you. I noticed that mypasswd.com was registered possibly after this example was put into the man pages. I couldn't find the exact date as the repo logs don't go back that far. Had you ever had any encounters with the domain owner Griffin de Luce? Looks like he wasn't a contributor or anything and eventually lost interest in harvesting /etc/passwd files from this example. My guess is that very few people ever really ran this so the problem is minimal. But I'm glad its fixed.

BTW, putting encrypted hashes into /etc/shadow was still an option in some versions of Linux in the late 90s at least. I remember Red Hat Linux had an option for enabling it and the default was not to enable it. So there could have been some password hash leakage, albeit, a long time ago.

@bagder

This comment has been minimized.

Show comment
Hide comment
@bagder

bagder Apr 6, 2016

Member

I honestly doubt anyone, ever, ran that command line verbatim. Well, until now when about 7 users had to try it out when they learned about this man page example.

I don't know Griffin and he/she has never been involved in the curl project as far as I can recall. I've never tried that command line myself and I've never visited that domain. I don't believe that the domain was registered or used because of that appearance in our docs.

Member

bagder commented Apr 6, 2016

I honestly doubt anyone, ever, ran that command line verbatim. Well, until now when about 7 users had to try it out when they learned about this man page example.

I don't know Griffin and he/she has never been involved in the curl project as far as I can recall. I've never tried that command line myself and I've never visited that domain. I don't believe that the domain was registered or used because of that appearance in our docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment