zhfliz

python has a number of these via pyupgrade, which are also included in ruff: https://docs.astral.sh/ruff/rules/#pyupgrade-up

it should be noted that this is different on Chrome https://browserleaks.com/chrome

it's free advertising

yes

Some online streamers have been hacked as of late using AI models trained to steal their passwords using the sounds of them typing on their keyboards

do you have any sources for that?

I've only seen this mentioned from research results recently but no real world exploitation reports.

https://www.bleepingcomputer.com/news/security/new-acoustic-...

it might have changed recently but i have previously created accounts by providing trash mailer addresses during creation.

at least in Germany it's not legal to require use of personal devices such as phones for your job.

No, as they never get loaded into the ssh binary and are external programs communicating over an interface.

my understanding is that the same would apply if you use ykcs11 in the OpenSSH agent instead of using it directly in `ssh`, which would make this a comparison between (OpenSSH agent + YKCS11) vs e.g., ssh-tpm-agent.

from the qualys report you linked:

Note to the curious readers: for security reasons, and as explained in the "Background" section below, ssh-agent does not actually load such a shared library in its own address space (where private keys are stored), but in a separate, dedicated process, ssh-pkcs11-helper.

additionally, as I understand it, this basically boils down to use-after-free due to unsafe code, which could occur in either agent implementation, even without loading an extra .so, although the presence of .so loading in general certainly does increase the attack surface.

`ssh-tpm-agent` is not dealing with secret material.

while the agent is certainly not accessing the private key directly, as long as you can access the agent and make it sign whatever you want, this will still be a very valuable vulnerability, with the only downside (compared to non-HSM keys) that you won't have persistent access to the private key, only temporary access for signing.

this can also be partially mitigated by requiring user interaction for every signing operation, but it's also not necessarily something that works for all use cases, such as when connecting to a few hundred destination hosts.

There is a separation of concerns here though.

when you compare (OpenSSH agent + YKCS11) to ssh-tpm-agent, they're both separated from the main `ssh` process and communicate through the SSH agent API.

PKCS11 allows you to use `ssh -I /path/to/lib.so` directly, which there doesn't seem to be a comparable alternative for in ssh-tpm-agent, so I'll ignore that feature for now.

are you extending this to the usage of yubikey-agent and ssh-tpm-agent as well?

both variants, whether it's using a PKCS11 provider using a standardized interface, or using a completely custom SSH agent, will need to deal with secret material.

although I'm no expert on the inner workings of SSH, I'd expect there to not be much difference between having the OpenSSH agent interface with ykcs11 (which is also open source and can be reviewed) and using an alternative agent with piv capabilities that was found on github.

have you considered using ykcs11?

ykcs11 allows you to use the native SSH agent (or even no agent at all for individual ssh invocations) with an ssh key on a yubikey using their pkcs11 provider.

https://developers.yubico.com/PIV/Guides/SSH_with_PIV_and_PK...

wow, didn't know about `ip --color`, that's awesome

people don't care about false positives on CGNAT either, so not much difference to the IPv4 situation if you target /64s

note that this is technically against their TOS if not using paid accounts:

One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that's fine, but it can only be used for running a machine)

https://docs.github.com/en/site-policy/github-terms/github-t...

Quantum CA (brand, not operator)/HiCA still can't issue certs for domains they don't "control" by having RCE on the systems they point to.

all CA requirements for validation still need to be fulfilled for issued certificates, as ssl.com, the Quantum CA operator, which exclusively holds the private keys, is a "proper" CA.

this does not affect the trust in the CA infrastructure or ssl.com itself; while this is morally questionable to keep the business relationship, it does not mean the CA is not following the signing requirements.

you're free to decide who to do business with if you're not providing a core utility service.

would you like to no longer receive water or electricity at your home because your utility companies don't like you, despite (being willing to) paying the bills like any other citizen?

even though not explicitly, i have already answered your question.

you should pass the transaction, as you should be in a neutral position.

edit: to clarify, payment providers/processors nowadays are a core utility function in our society. imo this is not something you can consider a regular private business.

at best you suspect it, you don't know it unless you're on the sending or receiving side of the transaction.

it shouldn't be my decision whether i want to allow the transaction, even if i wouldn't want to allow it. i'm not in a position to perform due legal process to determine whether you're indeed being paid for a hit job.

the provider should be in a neutral position.

you can also use it natively in non-browser applications.

just the other day i've used it in a CLI application (which authenticated against web, but without real browser): https://github.com/Yubico/python-fido2

if you know about/suspect it you report it.

how do you know with 100% certainty/due process that this is indeed the case and it's not just your ML algorithm going crazy?

people can also pay with physical money if they desire to do so.

while that may be useful to avoid dealing with torrents, many torrent clients support downloading only selected files from a torrent.

webauthn can very much be used in a desktop application, you're just losing the phishing resistance factor, as the application can choose what to send as identifier, which includes collecting tokens for other tools/websites.

requiring a paid license for updates just leads to people not installing security updates.

you can have some fun with nginx if you can identify on your backend whether the request is coming from a malicious source, e.g. with X-Accel-Limit-Rate

I strip the referrer generally via https://wiki.mozilla.org/Security/Referrer, unfortunately it breaks a small number of sites very badly, such as web.archive.org and a few others. some of them claiming it was done to combat scraping.

so they're trying to drive customers to those sites by making it even less desirable to not have automated solvers?

You shouldn't be taking my email just to demand lots of information from me after I already gave my email to you.

If you demand lots of information that should be clear right away.

Having an unused iCloud settings icon is hardly advertising

it's not just an unused iCloud settings icon.

it's a persistent red (1) that is always showing up in the settings app or in your dock while settings are open, indicating that something needs your attention.

there used to be no official way to disable this "reminder", though it seems that with Ventura it can finally be dismissed.

it wasn't stored on GitHub.

there's a json file on GitHub referencing the download of the source archive, stored on pypi infra.

in the tgz you can download from pypi you can find python code containing the secret.

https://github.com/orf/pypi-data/blob/main/release_data/i/h/...

note that not all enterprise setups use enterprise managed accounts.

you can also use GHE with unmanaged accounts that are still connected via SSO for approving access.

using enterprise managed accounts and unmanaged accounts on the same system can be quite annoying because you'll need to use different browser contexts (container tabs, separate browsers, etc.) and also different hostnames for ssh cloning to use different ssh keys.

https://docs.github.com/en/enterprise-cloud@latest/admin/ide...

https://docs.github.com/en/enterprise-cloud@latest/admin/ide...

how would domain fronting help with phishing?

your standard user agent (e.g. browser) will not send different values in SNI and HTTP Host header.

this is a deliberate action by the user agent to obscure the actual traffic destination.

this can of course be used both for censorship circumvention but also misleading corporate traffic inspection when TLS is not broken, though it's debatable whether that should work in the first place.