nostr:npub16panqlm27tnq3quttuuqrvzp7dk3rx2jv5l7c6w9yzljp26495hq0ysxgh out of frame was the French press
I don't mess around with breakfast
Anyone remember how everyone just had to have a bug guard or car bra?
The bugs didn't go away, we literally killed them all.
When was the last time you had to pull over just to get all the bugs off your windshield?
I have a weird memory of someone giving the Sega Seaman fish person thingy boobs
nostr:npub1yck44z5zqxmwpqzqs75ay6ffjdw843ng9p6mz0lzfff3fgz2djlsngujmw Straaaaange choice of wording.
And whether VLAN 1 has an actual VLAN ID value stamped into the frame header or not is imatterial to your described situation.
VLAN 1 being untagged is still logically batshit insane.
Disagree, if you're gonna have VLANs then making VLAN 1 be anything untagged is perfectly logical. I wouldn't want them to be separate, that's just a headache.
Chaotic evil: if everyone's gear actually let you use VLAN 0 I'd want that to be equivalent to anything untagged
nostr:npub1yck44z5zqxmwpqzqs75ay6ffjdw843ng9p6mz0lzfff3fgz2djlsngujmw What? No.... What? Huh? WTF?
This is not how VLANs work. Do you just, refuse to aknowledge the existance of VLAN pop and push operations, AKA.... access ports?
I can't even, what on Earth are you smoking?
You want all your access ports to be explicitly configured or not work, is what I mean. In case for some reason they're not admin down by accident
I'm far too lazy to monitor SNMP for this on my own network
nostr:npub1yck44z5zqxmwpqzqs75ay6ffjdw843ng9p6mz0lzfff3fgz2djlsngujmw
For starters, it depends on which side of this ridiculous debate you happen to agree with. Some vendors say VLAN 1 is a tagged frame, with a vlan id of one on it. I agree with this stance, as does Juniper.
Other vendors consider VLAN 1 is an untagged frame. They often call this the "native VLAN." On some platforms, one is merely the default, and it can be changed.
On others, VLAN 1 is always an untagged frame.
I consider both of these to be incorrect. A VLAN is a VLAN, and requires a tag. VLAN 1 shouldn't be some special case.
The biggest offender here is Cisco. They have products that do all three of these cases. This is due to the fact that so many of Cisco's products come from aquisittions. But the effect is the same, their own catalog isn't consistent.
I honestly don't know how most other vendors go at this point, because it is just so much safer avoiding VLAN 1 entirely. I never even find out. Have numerous Calix and A10 devices on my current network, I have no idea how either treats VLAN 1.
I'm gonna go with VLAN 1 is an untagged frame otherwise you can't have endpoints hanging off a layer 2 switch without themselves being VLAN aware and tagging their own frames, right?
I have run into this before when I was doing networking at an ISP and completely forgot about it until now.
I like requiring that your management VLAN be something specific and blocking vlan 1 / untagged entirely 😈
which vendors have compatibility issues here?
I have no doubt that companies push around sensitive data they've collected on us using XML. That's the type of insane bullshit you'd expect from bureaucracy.
Hey everyone, pretend this is a Github issue shitting on Google for destroying the web and please swarm it with 👍 reactions so they might address this vulnerability.
Getting this fixed might actually prevent some corporation holding your personal information from being attacked and having the data stolen in the future.
Wondering what other software out there is using xmerl and accepts public input and is vulnerable as a result.
May have to go digging through github later
nostr:npub108zt8c43ulvdwnax2txurhhr07wdprl0msf608udz9rvpd5l68ascvdkr5 nostr:npub108pv4cg5ag52nq082kd5leu9ffrn2gdg6g4xdwatn73y36uzplmq9uyev6 yeah, XXE. Means anything that can submit an XML document that the server parses can read arbitrary files on the server, same as the other issue. Actually worse if this doesn’t require Auth. XXE is fixed by not using a shit and brain-damaged parsers, which nobody should be using. This is straight outta 2004.
Abandon hope, all ye who enter. Pleroma is fucked and was made by retards.
The XML parser we're using is the most mature one in the ecosystem and comes with Erlang, but they apparently didn't care to disable this by default.
yeah seriously, I was looking at this like "I remember patching and documenting XXE bugs in FreeBSD packages like 10 years ago, how it this still a thing? Shouldn't everything be hardened against this by default because of all the SOAP exploits everyone was screaming about around 2010?"
This design by committee shit is inexcusable.
Also, personally, I think it's inexcusable to leave libraries vulnerable by default because of being afraid of breaking backwards compatibility which I assume is the reasoning here.
This is our BIND moment.
We get to have a million annoying little CVEs because we're so popular and everyone wants to attack us.
Although that means inevitably a few years from now our reputation will be destroyed and everyone will write their own implementations so they can recreate the same bugs from scratch.
I think this is an important audit we should make as a community so we can free ourselves of this cruft.
If anyone out there has information about this being required by something on the Fediverse I'd like to know. I'll try to do some research on it this weekend...
Looks like Mastodon's XML parsing library Nokogiri has this functionality disabled by default if anyone is wondering.