Have a look at dn42.

https://dn42.net/Home

The "malicious" code at the end of the advisory looks like nothing more than a beacon announcing it was installed?

  edit:
  get current working directory
  get username
  get hostname
  concatenate the last 3 together
  obfuscate(/encrypt?) this string
  send the result as a http request to 121.42.217.44 (the value of the base64 string)

php-cli scripts normally don't have an execution time limit (or a memory limit?), which makes them ideal for upgrades/database maintenance/cron jobs/etc while being able to reuse code from the application itself

one example: https://docs.moodle.org/22/en/Administration_via_command_lin...

The share links look like this

https:// send.firefox.com/download/<$file_identifier>/#<$encryption_key>

Data after the # in the url should not be sent to the http server by the client. Encryption/decryption is presumably handled in the users browser by JavaScript.

The statement about not having the ability to access the contents of the files is perhaps somewhat misleading as they do control the JavaScript that either creates the key or will be given access to the key when someone retrieves the file (by reading it off the end of the url).

part of this can be done with openSSH by setting the banner option in sshd_config.

"Banner The contents of the specified file are sent to the remote user before authentication is allowed. If the argument is ``none'' then no banner is displayed. By default, no banner is displayed."

Would (a) not be

  a. Cache files are added to when _something causes a request for_ IPFS content

The distinction being that "something" is not always a direct action from the user.

If content on IPFS (ie a web page?) can reference and load content from other addresses (assumption) then could someone end up in the situation where they are "hosting" (from the cache) something they would not expect to be? (until the garbage collection clears it).

If this seems far fetched, A submission to HN the other day seemed to surprise a few people[1] as it made a http request to a adult website to check if they had an active session (but did not display any content).

[1] https://news.ycombinator.com/item?id=12692389

For anyone wanting to do this, the profile and no-remote command line options[1] may be useful if you want to create shortcuts to launch specific profiles

You might also want to consider using a different theme[2] in each profile to help avoid mixing them up if your running multiple instances simultaneously.

My initial use case for this was adding the lets encrypt staging certificate authority to the trusted root certificate authorities in a profile only used for testing.

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Command_Lin... [2] https://addons.mozilla.org/en-US/firefox/themes/

If the attacker has ever seen the headers of a message you sent through fastmails SMTP service they have your public IP (Received from header) and can Dos you directly anyway.

They do something similar with their webmail service, but the data is encrypted so it can't be read by a third party.

https://www.fastmail.com/about/reportabuse.html (last paragraph)

EDIT: Fastmail is fairly priced (for me) and i like the features they offer but i wish they wouldn't do this (or rather, i wish they would do the same for the SMTP service as they do for the webmail service)

After some thought, The only advantage of signing before and after i can think of is without it you are left with the (theoretical?) problem of not knowing if the output from your implementation/version of the utility to decrypt/decompress is identical to the senders input to their implementation of the utility if the sender only signs the compressed/encrypted version.

Of course, if the compression/encryption method has some way of checking the integrity of the output (that's of equal strength to the signature) then then signing first would be completely redundant.

EDIT: so in many scenarios, signing first and last would have no advantage. For example if you get to decide what implementation will be used by the sender and the recipient (most package managers?)

Why is the debate about "compress/encrypt then sign" vs "sign then compress/encrypt"?

Is there a non obvious problem with sign then compress/encrypt then sign again? (overcomplicated or unnecessary?)