mbox

[bug#34632,0/2] Change from GSS to MIT-KRB5.

Message ID 20190223162042.18168-1-mbakke@fastmail.com
Headers show

Message

Marius Bakke Feb. 23, 2019, 4:20 p.m. UTC 
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?

Marius Bakke (2):
  gnu: gsasl: Use the MIT Kerberos implementation instead of GSS.
  gnu: curl: Build against MIT Kerberos instead of GSS.

 gnu/packages/curl.scm  | 10 ++++++----
 gnu/packages/gsasl.scm |  4 +++-
 2 files changed, 9 insertions(+), 5 deletions(-)

Comments

Maxim Cournoyer May 14, 2019, 3:17 a.m. UTC | #1 
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
Marius Bakke May 14, 2019, 6:15 p.m. UTC | #2 
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.
Maxim Cournoyer May 15, 2019, 11:06 p.m. UTC | #3 
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