Informational GSD for ReiserFS

[Kurt Seifried]

So ReiserFS is maybe being retired from the Linux Kernel (discussion https://lore.kernel.org/lkml/YhIwUEpy...@casper.infradead.org/). I think it makes sense to have an informational GSD here as anyone depending on it is going to have a bad time if they get caught by surprise (and I suspect by definition anyone still using ReiserFS is not paying attention to new filesystems). 

Conveniently enough SUSE has already done (in my opinion) the best solution here, for many years (SLES 15 is out):

Important: Support of ReiserFS in SUSE Linux Enterprise Server 12
Existing ReiserFS partitions are supported for the lifetime of SUSE Linux Enterprise Server 12 specifically for migration purposes. Support for creating new ReiserFS file systems has been removed starting with SUSE Linux Enterprise Server 12.

https://documentation.suse.com/sles/12-SP4/html/SLES-all/cha-filesystems.html#sec-filesystems-major-reiser

However, if I had to bet money I'd say there is at least one distro somewhere still shipping/using it, having an informational GSD talk about 1) that support is ending and 2) the subsequent risks (y2038 isn't that far away...) and 3) suggestions on solutions (ext4/xfs/btrfs) would be a helpful entry I feel. Thoughts/comments?

Kurt Seifried (He/Him) Chief Blockchain Officer and Director of Special Projects Cloud Security Alliance e: ksei...@cloudsecurityalliance.org

[Josh Bressers]

I think we can take a step back and ask should anything that goes EOL receive an identifier?

This would help trigger a finding in any sort of automated scanner if someone is running EOL software. I suspect we can all agree this is mostly a good thing.

While this seems like a good idea in theory, but I suspect it's too much at this time. The current view of vulnerability identifiers is that every finding is a real thing that poses some sort of significant risk (I know, this isn't really true). Many overwhelmed teams will likely see a list of EOL software as added work.

We may need some tooling to grow up first, then we can start being more proactive.

-- 

     Josh

--
You received this message because you are subscribed to the Google Groups "GSD Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gsd+uns...@groups.cloudsecurityalliance.org.

[Kurt Seifried]

On Wed, Feb 23, 2022 at 1:34 PM Josh Bressers <jo...@bress.net> wrote:

I think we can take a step back and ask should anything that goes EOL receive an identifier?

This would help trigger a finding in any sort of automated scanner if someone is running EOL software. I suspect we can all agree this is mostly a good thing.

While this seems like a good idea in theory, but I suspect it's too much at this time. The current view of vulnerability identifiers is that every finding is a real thing that poses some sort of significant risk (I know, this isn't really true). Many overwhelmed teams will likely see a list of EOL software as added work.

We may need some tooling to grow up first, then we can start being more proactive.

How should we tag this data so people can easily consume it, e.g. "vulnerability" vs "informational" vs "end of life"? I feel like a top level GSD tag that identifies what category(s) that entry fits into is the best way to go (e.g. don't make people guess/decipher it based on content or lack of content). 

 

-- 

     Josh