Re: libssh security announcements

[Rolf Eike Beer <eb@xxxxxxxxx>]

On Mittwoch, 24. September 2025 16:03:38 Mitteleuropäische Sommerzeit Jakub 
Jelen wrote:
> Hi Rolf,

Hi Jakub,

> Right now, all the advisories are based on the following template we have
> in our security process. But other people might follow it differently at
> times (or even same people at different times):
> 
> https://www.libssh.org/development/security-process/

yes, I already found that one.

> I agree that the version field is quite important so I would agree that
> having this field in some fixed format would help. So the simplest thing I
> can think of would be adjusting the template to help us make it more
> predictable with something like:
> 
> == Versions:    libssh >= X.Y.Z;  < A.B.C

That would be fine with me, just being consistent would be nice. I think you 
should define in advance how to write down something like "everything since 0.6 
up to 0.8.2 and 0.9.1", just because this will end up being written down 
differently if you don't, i.e. if you just want to have this as multiple lines 
of the same format, or multiple "< x" clauses, or …

> Regarding the JSON format, I am not much fan of that as it makes it harder
> both to read and to write for humans. Is this CVE schema used by the
> parties working with the CVEs? Would it make the creation and updating the
> advisories easier?

I think so, as that is what e.g. the kernel folks generate in their repo as 
well:

https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/published/
2019

Best is asking the RedHat security folks about that I guess. I personally find 
this format somewhat cumbersome as well, especially the version things. I just 
wanted to point it out in case you decide to go the extra mile.

While we are at it: could you nudge the RedHat security team to include the 
affected vanilla libssh versions in CVE-2025-8277 as well? Until now it only 
lists the affected RedHat distro versions (https://www.cve.org/CVERecord?
id=CVE-2025-8277).

> Most of the CVEs are straightforward, but some of the CVEs though affect
> either just the server, the client, some depend on the
> cryptographic backend (OpenSSL, libgcrypt, mbedtls), which we figured out
> that is easiest to describe in words

Sure thing. I personally would put this as an extra tag distinct from the 
version, like "Component: server, OpenSSL only". But please always put that in 
the text description as well, as I guess this is what will end up in the 
actual CVE description exclusively.

>> Which brings me to libssh-2025-gex.txt in this directory[2][3]. Should I
>> see this as independent vulnerability description without CVE id or is this
>> part of any other issue?
> 
> This was something where we wanted to attribute the reporters, but there
> was really no weakness. We were just not following protocol strictly in
> this specific case. We could justify a CVE for this so we ended up with
> just local advisory. Similarly we have some large audits here and not all
> of the findings got to CVE (but I thought we were putting them in
> advisories list, but probably not and they ended up just in the changelogs):
> 
> https://www.libssh.org/security/audit/

Absolutely fine with me, thanks for the clarification.

Regards,

Eike
-- 
Rolf Eike Beer

emlix GmbH
Headquarters: Berliner Str. 12, 37073 Göttingen, Germany
Phone +49 (0)551 30664-0, e-mail info@xxxxxxxxx
District Court of Göttingen, Registry Number HR B 3160
Managing Directors: Heike Jordan, Dr. Uwe Kracke
VAT ID No. DE 205 198 055
Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
Office Bonn: Bachstr. 6, 53115 Bonn, Germany
http://www.emlix.com

emlix - your embedded Linux partner

Attachment: signature.asc
Description: This is a digitally signed message part.