Privacy concerns regarding 0x0.st and the journal

mytArch · 2025-01-10 02:11:12

Sorry to interrupt, but I ran sudo journalctl -b | curl -F 'file=@-' 0x0.st out of curiosity not realising that the output is posted to a server (and it appears I don't have the authority to delete that file).
Am I correct in assuming that there's nothing posted in the file that I need to worry about going on the net like this?
Thanks and sorry again.

V1del · 2025-01-10 09:33:04

Please don't hijack threads for random questions that have no relation to what the thread was about... https://wiki.archlinux.org/title/Genera … _hijacking

No, the journal is not supposed to contain sensitive data and 0x0 will eventually remove pastes, assuming you still have the response headers (probably not...) you'll also have gotten a token that would allow you to delete files: https://0x0.st/ (navigate there with a browser, it gives you info on the deletion algorithm and how you can use the token you receive in the response to manipulate a given paste

Spltting from: https://bbs.archlinux.org/viewtopic.php?id=302438

Last edited by V1del (2025-01-10 14:35:24)

KIAaze · 2025-11-18 07:51:02

So how would one normally get the response headers?

i.e. how to submit to 0x0.st in such a way that you can delete posts there?

P.S.: I hope this is not hijacking the thread, as I was led here for exactly the same reason: privacy concerns regarding 0x0.st...

Last edited by KIAaze (2025-11-18 07:53:48)

mpan · 2025-11-18 08:03:00

It might be considered necrobumping, but in this case I believe it’s on-topic, and still both current and relevant. MytArch got a warning, because they posted in another, completely unrelated thread about Nvidia.

The -i option makes curl print response headers. The 0x0.st official site contains a collapsed list with details and examples on how to perform various actions and use the parameters.

KIAaze · 2025-11-18 10:07:52

Yes, thank you. I have just been looking into it in more detail. It would be nice if curl had a log somewhere, but then again, that might also be undesirable!

I thought curl was for web-related things, but seeing just 0x0.st made me assume that it was maybe writing to a file with that name, rather than a website. I really should have known better than running a command without checking...
Probably nothing risky uploaded, but it is still very annoying and I would not recommend that as a way to share logs, at least not without clearly stating what it does.
Simply adding "https://" in front of it would have helped.

the journal is not supposed to contain sensitive data

Yes, but it can. A very simple example: Accidental entering of passwords in username fields get logged as failed login attempts with the username and therefore the password.
I'm sure there are other cases.
And the username alone might be a privacy concern. As well as any running services, software, etc.

Anyway, here is my detailed summary of alternative commands, with both short and long flags:

# Method 1: verbose output
-v, --verbose: Make  curl output verbose information during the operation.
echo $RANDOM | curl --verbose --form 'file=@-' https://0x0.st
echo $RANDOM | curl -v -F 'file=@-' 0x0.st

# Method 2: dump header to file
-D, --dump-header <filename> : (HTTP FTP) Write the received protocol headers to the specified file.
echo $RANDOM | curl --dump-header 0x0.header.txt --form 'file=@-' https://0x0.st
echo $RANDOM | curl -D 0x0.header.txt -F 'file=@-' 0x0.st

# Method 3: dump header to stdout
-i, --show-headers : (HTTP FTP) Show response headers in the output.
echo $RANDOM | curl --show-headers --form 'file=@-' https://0x0.st
echo $RANDOM | curl -i -F 'file=@-' 0x0.st

# Method 4: get only token
-w, --write-out <format> : Make curl display information on stdout after a completed transfer. Output HTTP header values from the transfer's most recent server response by using %header{name} where name is the case insensitive name of the header (without the trailing colon).
echo $RANDOM | curl --write-out 'X-Token: %header{X-Token}\n' --form 'file=@-' https://0x0.st
echo $RANDOM | curl -w 'X-Token: %header{X-Token}\n' -F 'file=@-' 0x0.st

# Delete file from https://0x0.st:
curl --form token=token_here --form delete= https://0x0.st/abc.txt
curl -F token=token_here -F delete= https://0x0.st/abc.txt

Last edited by KIAaze (2025-11-18 12:00:39)

seth · 2025-11-18 13:55:47

I thought curl was for web-related things

It is: https://man.archlinux.org/man/curl.1

at least not without clearly stating what it does

I really should have known better than running a command without checking...

PSA: don't type random shit you don't grasp into an interactive shell.
There could *MUCH* worse happen than that.

Yes, but it can. A very simple example: Accidental entering of passwords in username fields get logged as failed login attempts with the username and therefore the password.

https://wiki.archlinux.org/title/Audit_ … d_messages

And the username alone might be a privacy concern. As well as any running services, software, etc.

You're not sharing the journal for no reason, right?
If you're worried sharing information about your running services you should absolutely not seek help on a public forum but hire some compentent IT.

KIAaze · Yesterday 23:03:50

As a solution for any future users ending up here with the same concern:
If you don't have the management tokens, you can contact the admin of https://0x0.st/ to request a file removal, using the details under "Abuse and Takedown Requests" (there is even a PGP public key!).

@seth: Thanks for the audit rules. That might be useful.

Last edited by KIAaze (Yesterday 23:04:36)

mpan · Today 00:27:46

edit: oops! I misread, corrected. (thanks, seth)
No need to bother mia in person.

curl -Ftoken=TOKEN -Fdelete= https://0x0.st/IDENTIFIER

Last edited by mpan (Today 12:12:27)

seth · Today 08:29:45

KIAaze wrote:

If you don't have the management tokens

The also copypasted the curl examples (more or less) from 0x0.st

Fwwi, the reason why this is handed around in the shortmost form is that users will typically find themselves having to do this from the console and also,
PSA: you cannot "unbreach" secrets
If you ever find yourself publishing sensitive data the only correct response to that is to invalidate the sensitive data!

Arch Linux

#1 2025-01-10 02:11:12

Privacy concerns regarding 0x0.st and the journal

#2 2025-01-10 09:33:04

Re: Privacy concerns regarding 0x0.st and the journal

#3 2025-11-18 07:51:02

Re: Privacy concerns regarding 0x0.st and the journal

#4 2025-11-18 08:03:00

Re: Privacy concerns regarding 0x0.st and the journal

#5 2025-11-18 10:07:52

Re: Privacy concerns regarding 0x0.st and the journal

#6 2025-11-18 13:55:47

Re: Privacy concerns regarding 0x0.st and the journal

#7 Yesterday 23:03:50

Re: Privacy concerns regarding 0x0.st and the journal

#8 Today 00:27:46

Re: Privacy concerns regarding 0x0.st and the journal

#9 Today 08:29:45

Re: Privacy concerns regarding 0x0.st and the journal

Board footer