Notices by Wolf480pl (wolf480pl@mstdn.io), page 8

@makdaam @domi @lanodan
don't worry about thread necromancy, it hasn't even been a week yet

So you're saying that the checkbox exists purely for performative/blameshifting purposes?

I think even if that is true, the side effect of complying with the checkbox is doing some good things. In this case - how do you make the CVE scanner happy without patching at least some vulns?

And if you patch some vulns, you're already doing better than those who don't give a fuck.

1/

@denza252 god I wish

@piggo my first LAN had an 8-port switch that had 2 LEDs for each port: green for link, and amber to indicate speed.

Amber LED on = 100Mbit/s
Amber LED off = 10Mbit/s

100Mbit was fast back then.

Both were faster than my internet connection

@lanodan @domi @rozenglass @ignaloidas
Still, OpenWRT exists and supports a bunch of routers, and LineageOS exists and supports a bunch of phones.

Is it 100% open-source? No.
But it's enough that you can modify a lot of the interesting behaviours of the device.

I've never seen custom firmware for a non-Linux router.

I've heard there were firmware mods for Symbian phones, but AFAIK they were much more limited in what they change

@ignaloidas @lanodan @domi @rozenglass is there any development model other than Linux's that'd ensure we get enough source code that we can build custom firmware for these devices?

@ignaloidas @lanodan @domi @rozenglass
them moving away from Linux would be a shame - I don't want a VxWorks wifi router :(

@lanodan @domi @rozenglass
IIRC Linux intentionally files a CVE for every bugfix backported to stable that fixes anything related to memory safety, permission checks, etc.

They amount of bugfixes is too high for kernel devs to evaluate exoloitability of each of them, therefore it's also too high for you. They don't want you to read the CVEs. They want you to blindly update to latest patch release in your LTS branch.

@lanodan @domi
Ok so @rozenglass you're saying running at zero CVEs published should be a really low bar

But consider that Greg K-H just said:

> Given the news of the potential disruption of the CVE main server, I've reserved 1000 or so ids for the kernel now, which should last us a few weeks.

That's just Linux kernel.
Who is going to have the resources to review 1000 CVEs in every few weeks?

@lanodan @domi @rozenglass at my $dayjob, if I showed management such a list, they'd be like "this list is too long, we'll never be able fix all those issues, and 90% of them are probably bullshit, try making a shorter, more relevant list"

But well, the stuff we do is fairly unimportant. If it fails, nobody dies, just some people won't see ads...

@lanodan @domi @Eldeberen
but then there's no cost for depending on many small libraries...

@lanodan @domi @Eldeberen
oh, because if you don't pin or vendor, then your version number does uniquely determinie a transitive dependency's version number

@Eldeberen
should each dependency manage their transitive CVEs?

As in, if I depend on library X, and library X depends on library Y, and there's the a vuln in library Y, then should the devs of library X:
- evaluate if the vuln in Y is applicable to the way X uses Y
- if so, find out what uses of X the vuln applies to, and
- re-publish it in their own security.xml, with the info about applicability?

@domi @lanodan

@lanodan @domi does it apply to SaaS?

@lanodan @domi
does it only apply to companies that sell physical objects?

@lanodan @domi
> code to audit through

LMAO

@lanodan @domi
okay, so now that packaging team would be the one to subscribe to security feeds, read changelogs, decide when to bump the version, or backport patches when upstream does not have a backwards-compatible version?

And when a developer wants to try out a new library, he needs to wait for the packaging team to add it to the distro overlay?

@lanodan @domi
by "API" I mean "does it still work if I update the library at the source code level"

but yeah, checking if things work with a new version is hard.

> should have a packaging team

you mean contributing to the upstream distro, or rolling our own downstream distro?

@lanodan @domi
yeah, in an ideal world, all libs would have stable APIs and be packaged by distros.

And any given project would have like 10 direct dependencies and 50 transitive ones.

Unfortunately, Python...

@lanodan @domi
I think part of the problem with CVEs is that they serve two purposes without people realizing.

Similar to how issue trackers ended up serving as both a todo list / task management database, and as a defect database, leading to the shitshow called stalebot.

In case of CVEs, that'd be a difference between "this can definitely be exploited" and "this might be exploitable so apply the bugfix just in case" - IMO both are needed but for different purposes.

Assuming both have excellet drivers for your OS of choice, would you rather have a switch chip do hardware L3 routing for you, or just flow offload?

The latter lets you apply normal firewall rules to the first packet of every connection and then decide if subsequent packets of that flow should be handled by the hardware, or still sent to the CPU.

But I'm guessing it's also slow if you have a lot of short-lived connections...