This time it's Mozilla. They apparently forgot to regenerate some certificates used in signing add-ons and they all stopped working.
https://www.reddit.com/r/firefox/comments/bkfte9/if_you_have_issues_with_your_addons_being_marked/
This time it's Mozilla. They apparently forgot to regenerate some certificates used in signing add-ons and they all stopped working.
https://www.reddit.com/r/firefox/comments/bkfte9/if_you_have_issues_with_your_addons_being_marked/
So our company procured, after years of selection and testing, a tool to manage shared passwords (where a team needs access to systems that cannot be easily connected to the federated authentication). So I tried to add the secrets for the service principal and the technical user in there and
⸘Warum, kurwa‽
… the “password” in this case is a “client secret” and is (hopefully) randomly generated by the Azure API, so I can't choose whether it will start with a digit or not.
PS: Note the bonus Engrish.
@Polygeekery I doubt you'll make friends that way, because:
@sh_code It's not JavaScript that's kidding you:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html:
The <time.h> header shall declare the tm structure, which shall include at least the following members:
int tm_sec Seconds [0,60].
int tm_min Minutes [0,59].
int tm_hour Hour [0,23].
int tm_mday Day of month [1,31].
int tm_mon Month of year [0,11].
int tm_year Years since 1900.
int tm_wday Day of week [0,6] (Sunday =0).
int tm_yday Day of year [0,365].
int tm_isdst Daylight Savings flag.
Javascript just passes those values on.
I would, however, grant you that the getDate
for day and getDay
for day-of-week is somewhat silly.
@obeselymorbid Healthy Living hasn't been available in most of the world for almost two years now
I just got
from GitHub.
How on $planet does GitHub suddenly decide that an account that exists for some years, has repositories, has comments in many bug reports that are not being marked as spam, has integrated merge requests and is member of two organizations is not a human?
@LaoC said in Hacking News:
I see no reason to switch. Supposedly the algorithm is faster (which doesn't matter at all in SSH), but DJB & Tanja Lange say it's crap and quite a few things coming out of NIST turned out to be smelly so I would prefer not to.
The https://safecurves.cr.yp.to/ (by DJB & Lange) lists the NIST P-256 and P-384 as manipulatable, because they include an unexplained pseudo-random constant, but it does not list the P-521. It does list “E-521”, which someone said is the same curve here, but https://neuromancer.sk/ doesn't seem to agree (P-521, E-521).
@Zecc said in In other news today...:
Just when I thought I couldn't hate advertisers more than I do.
Advertising is both the driving force of modern society and its future downfall.
Without advertising, people wouldn't be buying a lot of the shit they do, because it wouldn't even cross their minds they could want something like that, which would mean economy wouldn't grow as fast and the progress would be slower, though we'd probably have more time on our hands. But with advertising getting ever more aggressive as it is wont to get, we'll sooner or later drown in useless junk and visual and audible smog.
… it crossed my mind to check what CFSSL supports[1]¹, and it looks like they offer:
rsa
) size ∈ 〈2048, 8192〉 bitsecdsa
) size ∈ {256, 384, 521} (the P-256, P-384 and P-521 curves)ed25519
) (size ignored, it's just one curve)so that's probably the set that's actually usable. If Microsoft support EC at all, that is.
And their default is actually ecdsa
size 256.
¹ Use the source, Luke. I didn't even bother trying the documentation, I already know it sucks.
@dkf It is completely irrelevant that it can also be using a non-ssh transport, the point is it is using a different implementation of ssh transport than the one affected by the security advisory.
@Carnage said in The Official Funny Stuff Thread™:
English is NOT THIS crazy.
The pronunciation changes over time a lot faster than the spelling, which is held fixed by by long history of written texts, especially literature. But the pronunciation doesn't change randomly, there are patterns to it, and therefore the correspondence from letters to sounds does follow those patterns. Not very regularly, and there are several ways some phonemes could evolve, but it still isn't just random.
@DogsB And that's supposed to be news to whom, exactly? I thought everybody (who cared at least somewhat anyway) already knows that.
Everybody I know has always been generating X.509 (TLS) certificates using algorithm¹ RSA
, because it's traditional and because it only takes one parameter, the size.
But recently I've seen some proposal that stipulated algorithm¹ EC
with curve secp384r1
² for a project CA, also stating other algorithm like Ed25519
might be considered for the subordinate keys, and we just discussed vulnerability concerning P-521, which openssl would know as EC
secp521r1
, in putty.
The matter is further complicated by the fact that
keyUsage
.Does anybody know of a guide on what to use for which purpose, usable by average developer or devops engineer? My google/duck/etc.-fu is failing me.
¹ As in openssl genpkey -algorithm
option.
² The -pkeyopt ec_paramgen_curve:
option.
@Arantor said in Hacking News:
@Bulb Git on Windows is a generally unmitigated shitshow.
Which has exactly nothing to do with the issue at hand, because the standard install of git uses openssh, not putty, for transport, and does not even offer an option to sign anything with ssh (only with gpg).
@HardwareGeek linked an article in Hacking News that said:
There are instances where this vulnerability can be exploited without the need to compromise a server in advance.
One such case is the use of SSH keys for signing Git commits. A common setup involves using Pageant, the ssh-agent of PuTTY, locally and forwarding the agent to a development host.
Here, you configure Git to use OpenSSH to sign Git commits with the SSH key provided by Pageant. The signature is then generated by Pageant, making it susceptible to private key recovery.
Who in their right mind does that‽
Git commits should be signed by keys that are part of some public key infrastructure, but SSH doesn't have any method of signing certificates or even certificates at all. And while it uses the same algorithms as PGP/GPG or X.509, there is no sane reason to actually use the same key with it.
On the other hand
Collecting signatures from an SSH server is not as critical as it would mean the server itself is already compromised, and thus, the threat actor has broad access to the operating system.
Yes, it is, because the normal use-case is that the user has one key and uses it to access all systems they administer, so if one server is compromised, stealing the keys allows getting to those other systems.
Either way, the attack affects
NIST P-521 curve
Has anybody already started using that? I've been using the smaller ed25519 curve for over a decade, but still have to have an RSA key for quite a few systems that don't support it.
Also it is funny that the exploit affects the longer key while the shorter ones remain safe.