<andi->
I started moving towards brainstorming what kind of notes/metadata/classification/... file format one would like to use for half human and half machine readability. Goals should proably be painless for humans to add classifications and notes (links to patches, longer rants, ...) but also allow a machine to figure out why this issue is not important, if it was forgottoen or whatever
<andi->
yay, my host where I do a HEAD against the NVD database a few times per hour has been "blackholed" on their end -,-
<pie_>
sexpressions
<pie_>
always sexpressions
<pie_>
:p
* ekleog
would vote for no toml, but something a bit more standard when outside of the strictly-Rust circle
<ekleog>
Also, wontfix is something that sounds a bit too strong for something that might end up being read by unaware users, even though I myself used it for lack of a better term… maybe `nonsa`, to mirror `nodsa` ?And `nsa` for “Nix Security Advisories” would make a pretty neat pun 😇
<ekleog>
Anyway, I think something that states “This is really low-priority, so won't get in a security advisory, but feel free to fix it if you feel like it” would sound better, even though a good name is hard to come up with :/
* ekleog
also added his opinions at the end of the pad, so that people could just +1 / -1 if they don't feel like answering
<samueldr>
the layer of FUD being thrown around with all ME-related makes it so hard to actually know the extent :(
<samueldr>
as soon as someone asks "Do these require AMT to be activated?"
<samueldr>
all that's thrown around is "ME cannot be fully deactivated"
<samueldr>
well, gee, thanks
<andi->
We will be stuck with "broken MEs" for a while. AMT is also (as it seems) a piece of software that never received any audit.. At least disabling that (properly?) Is possible in most BIOS setups.
<samueldr>
yes, I'm not excusing ME and even kinda hate how you cannot replace AMT, but let's be fair here, AMT != ME
<samueldr>
(I would love being able to put my own software in place of the AMT, and have the ability to actually zeroing it out)
<andi->
I don't know enough to say where the exact boundaries are between those systems and how they access each other internally.
<samueldr>
(yeah, that's probably another issue I didn't really think about)
<andi->
The way I understood it so far (not quoteable, no source) is that the ME might be able to control (start, reset, configure,...) AMT but not the other way around
<pie_>
wasnt there some stuff going around at some point about at least largely crippling ME
<joepie91>
andi-: oof, this looks like it's going to be an inode nightmare
<andi->
maybe :/
<andi->
I am thinking that an sqlite db might not be to bad after all and a textfile for each CVE containing the (meta) data that we want to annotate
<joepie91>
andi-: likely a better idea, yeah
<andi->
how would we solve multi-user access/mofifications?
<andi->
A glorified server that hosts the database (as debian does)?
<joepie91>
andi-: does the 'database' contain any human-specified data??
<joepie91>
?*
<joepie91>
or just generated?
<andi->
well it is generated right now but to generate that you need a larger set of data
<andi->
well "larger" meaning 9MB of json for the unstable channel..
<andi->
mhm
<joepie91>
andi-: I guess a better question is, would it be reasonable to expect DB (non-annotation) updates to come from multiple sources? and would it be reasonable to include it in the git repo at all?
<joepie91>
or would it be a better option to treat the DB as a blob that can come from anywhere, and only version-control human annotations?
<andi->
well the git repo was an attempt to have an "offline" database that we can distribute easily and modify locally
<andi->
I would like to have no blobs that might do magic. THe idea is that everyone can understand and reproduce the things..
<joepie91>
that answer doesn't really give me the frame of reference I'm looking for though :P
<joepie91>
reason for my question is that you could otherwise just throw in an sqlite DB as a single file in the repo, with the human-edited annotations next to it
<joepie91>
but this will only work if there are no eg. merge conflicts to resolve on the sqlite DB
<joepie91>
ie. if the DB is updated centrally by one party
<andi->
I would not commit that DB. Neither as blob nor as text dump.
<andi->
I would then try to encourage people to use my (or any) archive of scan results to reconstruct the DB
<andi->
the annotations would be the only thing that would be stored in a repository
<andi->
changing the directory layout into an sqlschema shouldn't be too harcd