| Message ID | 20190223162042.18168-1-mbakke@fastmail.com |
|---|---|
| Headers | show |
| Series | Change from GSS to MIT-KRB5. | expand |
On Sat, Feb 23, 2019 at 05:20:42PM +0100, Marius Bakke wrote: > The GNU Generic Security Service and friends have been unmaintained for > many years now: <https://www.gnu.org/software/gss/>. > > Since these libraries are security-critical, it would be good to switch > to maintained implementations. WDYT? I think it's the right choice.
Hello, Leo Famulari <leo@famulari.name> skribis: > On Sat, Feb 23, 2019 at 05:20:42PM +0100, Marius Bakke wrote: >> The GNU Generic Security Service and friends have been unmaintained for >> many years now: <https://www.gnu.org/software/gss/>. >> >> Since these libraries are security-critical, it would be good to switch >> to maintained implementations. WDYT? > > I think it's the right choice. Yeah, it’s a bit sad IMO, but so be it. Note that “guix refresh -l gss” says 4K packages depend on it, not sure why. Thanks, Ludo’.
Hello! On Sat, Feb 23, 2019 at 05:20:42PM +0100, Marius Bakke wrote: > The GNU Generic Security Service and friends have been unmaintained for > many years now: <https://www.gnu.org/software/gss/>. > > Since these libraries are security-critical, it would be good to switch > to maintained implementations. WDYT? Unmaintained on what ground? The website doesn't list fresh news, but the latest release was made in 2014 [1], and the maintainer has made changes to the Debian package last time in 2017 [2]. I wouldn't say it's unmaintained until the maintainer says so or CVEs pile up unfixed (which there aren't). So, my position would be to not do anything, as there doesn't seem to be an issue. Maxim [1] ftp://ftp.gnu.org/gnu/gss/ [2] https://sources.debian.org/src/gss/1.0.3-3/debian/changelog/
On Fri, Mar 15, 2019 at 11:43:26PM -0400, Maxim Cournoyer wrote: > Unmaintained on what ground? The website doesn't list fresh news, > but the latest release was made in 2014 [1], and the maintainer has made > changes to the Debian package last time in 2017 [2]. I wouldn't say it's > unmaintained until the maintainer says so or CVEs pile up unfixed (which > there aren't). Considering the rate of vulnerability discovery in MIT Kerberos [0] I think that, if GSS was being examined to the same degree, we would learn of many serious bugs. Any significant C codebase of this age will have such bugs. But unfortunately GSS hasn't received as much scrutiny. [0] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=krb5
Hello, Leo Famulari <leo@famulari.name> writes: > On Fri, Mar 15, 2019 at 11:43:26PM -0400, Maxim Cournoyer wrote: >> Unmaintained on what ground? The website doesn't list fresh news, >> but the latest release was made in 2014 [1], and the maintainer has made >> changes to the Debian package last time in 2017 [2]. I wouldn't say it's >> unmaintained until the maintainer says so or CVEs pile up unfixed (which >> there aren't). > > Considering the rate of vulnerability discovery in MIT Kerberos [0] I > think that, if GSS was being examined to the same degree, we would learn > of many serious bugs. Any significant C codebase of this age will have > such bugs. But unfortunately GSS hasn't received as much scrutiny. > > [0] > https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=krb5 Just FYI, I had ping'd the GSS mailing list with this message: http://lists.gnu.org/archive/html/help-gss/2019-03/msg00001.html, but there haven't been a reply (yet). So it looks like it was a wise decision to make the switch! Sorry for doubting, eh! Maxim
Hi Maxim, Maxim Cournoyer <maxim.cournoyer@gmail.com> writes: > Hello, > > Leo Famulari <leo@famulari.name> writes: > >> On Fri, Mar 15, 2019 at 11:43:26PM -0400, Maxim Cournoyer wrote: >>> Unmaintained on what ground? The website doesn't list fresh news, >>> but the latest release was made in 2014 [1], and the maintainer has made >>> changes to the Debian package last time in 2017 [2]. I wouldn't say it's >>> unmaintained until the maintainer says so or CVEs pile up unfixed (which >>> there aren't). >> >> Considering the rate of vulnerability discovery in MIT Kerberos [0] I >> think that, if GSS was being examined to the same degree, we would learn >> of many serious bugs. Any significant C codebase of this age will have >> such bugs. But unfortunately GSS hasn't received as much scrutiny. >> >> [0] >> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=krb5 > > Just FYI, > > I had ping'd the GSS mailing list with this message: > http://lists.gnu.org/archive/html/help-gss/2019-03/msg00001.html, but > there haven't been a reply (yet). > > So it looks like it was a wise decision to make the switch! Sorry for > doubting, eh! Thank you very much for checking with upstream :-) I was on the fence about this switch myself, and submitted this patch hoping for feedback along these lines. It would be great to get Shishi and GSS into Googles OSS-Fuzz and similar so that we can be more confident in the implementation. For now I've pushed these patches in 996186b..828d376.
Hello Marius, Marius Bakke <mbakke@fastmail.com> writes: [...] >>> Considering the rate of vulnerability discovery in MIT Kerberos [0] I >>> think that, if GSS was being examined to the same degree, we would learn >>> of many serious bugs. Any significant C codebase of this age will have >>> such bugs. But unfortunately GSS hasn't received as much scrutiny. >>> >>> [0] >>> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=krb5 >> >> Just FYI, >> >> I had ping'd the GSS mailing list with this message: >> http://lists.gnu.org/archive/html/help-gss/2019-03/msg00001.html, but >> there haven't been a reply (yet). >> >> So it looks like it was a wise decision to make the switch! Sorry for >> doubting, eh! > > Thank you very much for checking with upstream :-) > > I was on the fence about this switch myself, and submitted this patch > hoping for feedback along these lines. > > It would be great to get Shishi and GSS into Googles OSS-Fuzz and > similar so that we can be more confident in the implementation. Would it be possible to add a fuzz phase to our GNU build system? If it's not too expensive to run, it could be a security enhancer for the Guix System! AFL (which is one of the two fuzzers used by Google's OSS-fuzz service, and which we already have in Guix). Food for thoughts! > For now I've pushed these patches in 996186b..828d376. Thank you, Maxim