[PATCH 0/2] Change from GSS to MIT-KRB5.

Done

Details

6 participants

Simon Josefsson via Discussion list for GNU Generic Security Service
Leo Famulari
Ludovic Courtès
Maxim Cournoyer
Marius Bakke
Simon Josefsson

Owner: unassigned

Submitted by: Marius Bakke

Severity: normal

Marius Bakke wrote on 23 Feb 2019 17:20

Recipients:(address . guix-patches@gnu.org)

Message-ID:20190223162042.18168-1-mbakke@fastmail.com

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(-)

2.20.1

Marius Bakke wrote on 23 Feb 2019 17:23

[PATCH 1/2] gnu: gsasl: Use the MIT Kerberos implementation instead of GSS.

Recipients:(address . 34632@debbugs.gnu.org)

Message-ID:20190223162338.18429-1-mbakke@fastmail.com

* gnu/packages/gsasl.scm (gsasl)[inputs]: Change from GSS to MIT-KRB5.
[arguments]: New field.
---
 gnu/packages/gsasl.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Toggle diff (19 lines)diff --git a/gnu/packages/gsasl.scm b/gnu/packages/gsasl.scm
index 127b476ef3..9296f3d80f 100644
--- a/gnu/packages/gsasl.scm
+++ b/gnu/packages/gsasl.scm
@@ -95,9 +95,11 @@ the underlying security implementation.")
                   (("test-lock\\$\\(EXEEXT\\) ") ""))
                 #t))))
    (build-system gnu-build-system)
+   (arguments
+    `(#:configure-flags '("--with-gssapi-impl=mit")))
    (inputs `(("libidn" ,libidn)
              ("libntlm" ,libntlm)
-             ("gss" ,gss)
+             ("mit-krb5" ,mit-krb5)
              ("zlib" ,zlib)))
    (propagated-inputs
     ;; Propagate GnuTLS because libgnutls.la reads `-lnettle', and Nettle is a
-- 
2.20.1

Marius Bakke wrote on 23 Feb 2019 17:23

[PATCH core-updates 2/2] gnu: curl: Build against MIT Kerberos instead of GSS.

Recipients:(address . 34632@debbugs.gnu.org)

Message-ID:20190223162338.18429-2-mbakke@fastmail.com

* gnu/packages/curl.scm (curl)[inputs]: Change from GSS to MIT-KRB5.
[arguments]: Adjust accordingly.
---
 gnu/packages/curl.scm | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

Toggle diff (41 lines)diff --git a/gnu/packages/curl.scm b/gnu/packages/curl.scm
index b1b2b999a2..88abc6aabd 100644
--- a/gnu/packages/curl.scm
+++ b/gnu/packages/curl.scm
@@ -37,8 +37,8 @@
   #:use-module (gnu packages compression)
   #:use-module (gnu packages golang)
   #:use-module (gnu packages groff)
-  #:use-module (gnu packages gsasl)
   #:use-module (gnu packages guile)
+  #:use-module (gnu packages kerberos)
   #:use-module (gnu packages libidn)
   #:use-module (gnu packages openldap)
   #:use-module (gnu packages perl)
@@ -63,10 +63,10 @@
    (outputs '("out"
               "doc"))                             ;1.2 MiB of man3 pages
    (inputs `(("gnutls" ,gnutls)
-             ("gss" ,gss)
              ("libidn" ,libidn)
              ("libssh2" ,libssh2)
              ("openldap" ,openldap)
+             ("mit-krb5" ,mit-krb5)
              ("nghttp2" ,nghttp2 "lib")
              ("zlib" ,zlib)))
    (native-inputs
@@ -85,8 +85,10 @@
            (separator #f)                         ;single entry
            (files '("etc/ssl/certs/ca-certificates.crt")))))
    (arguments
-    `(#:configure-flags '("--with-gnutls" "--with-gssapi"
-                          "--disable-static")
+    `(#:configure-flags (list "--with-gnutls"
+                              (string-append "--with-gssapi="
+                                             (assoc-ref %build-inputs "mit-krb5"))
+                              "--disable-static")
       ;; Add a phase to patch '/bin/sh' occurances in tests/runtests.pl
       #:phases
       (modify-phases %standard-phases
-- 
2.20.1

Leo Famulari wrote on 26 Feb 2019 05:58

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

Recipients:(name . Marius Bakke)(address . mbakke@fastmail.com)(address . 34632@debbugs.gnu.org)

Message-ID:20190226045813.GA29580@jasmine.lan

On Sat, Feb 23, 2019 at 05:20:42PM +0100, Marius Bakke wrote:

Toggle quote (6 lines)

> 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.

Ludovic Courtès wrote on 15 Mar 2019 23:14

Recipients:(name . Leo Famulari)(address . leo@famulari.name)

Message-ID:87tvg323ak.fsf@gnu.org

Hello,

Leo Famulari <leo@famulari.name> skribis:

Toggle quote (9 lines)

> 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’.

Maxim Cournoyer wrote on 16 Mar 2019 04:43

Recipients:(address . mbakke@fastmail.com)

Message-ID:87o96bqyap.fsf@gmail.com

Hello!

On Sat, Feb 23, 2019 at 05:20:42PM +0100, Marius Bakke wrote:

Toggle quote (6 lines)

> 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/

Leo Famulari wrote on 17 Mar 2019 19:27

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:20190317182705.GD1410@jasmine.lan

On Fri, Mar 15, 2019 at 11:43:26PM -0400, Maxim Cournoyer wrote:

Toggle quote (6 lines)

> 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

Maxim Cournoyer wrote on 14 May 2019 05:17

Recipients:(name . Leo Famulari)(address . leo@famulari.name)

Message-ID:87o9457miq.fsf@gmail.com

Hello,

Leo Famulari <leo@famulari.name> writes:

Toggle quote (15 lines)> 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 wrote on 14 May 2019 20:15

Recipients:

Message-ID:87v9ycaomv.fsf@fastmail.com

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (28 lines)> 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.

Closed

Maxim Cournoyer wrote on 16 May 2019 01:06

Recipients:(name . Marius Bakke)(address . mbakke@fastmail.com)

Message-ID:8736lftj08.fsf@gmail.com

Hello Marius,

Marius Bakke <mbakke@fastmail.com> writes:

[...]

Toggle quote (25 lines)>>> 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!

Toggle quote (2 lines)

> For now I've pushed these patches in 996186b..828d376.

Thank you,

Maxim

Closed

Simon Josefsson wrote on 6 Aug 2022 16:04

Re: Archived problem report bug#34632 (GSS development status)

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87mtchtqn8.fsf@latte.josefsson.org

unarchive 34632

-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCYu502xQcc2ltb25Aam9z

ZWZzc29uLm9yZwAKCRBRcisI/kdFohjbAQCXgwUtf+c67vr480ptD1M/kJ1qKLM7

J4I0Jp2FLRgGHwEAmtvi0XDbgfk3DtjlBV5h4H6JTxU3jNK61YHIqnb3MgE=

=p9jG

-----END PGP SIGNATURE-----

Simon Josefsson via Discussion list for GNU Generic Security Service wrote on 6 Aug 2022 16:02

Re: GSS development status

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:87r11ttqq0.fsf@latte.josefsson.org

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (17 lines)> Hello,
>
> I'd like to inquire about the development status of GSS? Has it left the
> beta status? Are bugs still being fixed? Is there any known or presumed
> security issues when using GSS rather than its more mainstream
> implementation in MIT Kerberos?
>
> I'm asking because the GNU Guix project is considering a switch from GNU
> GSS to MIT krb5 for security reasons [0], given that no new releases have
> been made since 2014.
>
> Thank you,
>
> Maxim Cournoyer
>
> [0]  http://issues.guix.info/issue/34632

Hi Maxim,

Sorry for the slow response, which may in part be an answer to your

question. However I have just released GNU GSS version 1.0.4 to refresh

the project, and have setup CI/CD checking of it to pave the road for

future improvements. To my knowledge there are only two major missing

features:

1) Missing gss_wrap() AES functionality. This prevents SASL GSS-API

to complete on modern machines. Shishi supports AES and GSSLib

supports it for GSS_Init_sec_context etc but not GSS_wrap.

2) Shishi doesn't use the same ccache/keytab files as MIT Kerberos and

Heimdal.

I hope to complete 1) in the future. For 2), fixing it would be a GNU

Shishi feature that should be simple to resolve -- it ships with tools

ccache2shishi and keytab2shishi to convert the files, but that should be

done automatically internally by the library instead.

Indeed getting these enrolled in the OSS Fuzz project would be a great

contribution. My primary goal is to do a new release of GNU Shishi and

improve the CI/CD integration checks to have good confidence in future

changes.

Regarding what 'gsasl' and 'curl' should be linked against in GNU Guix,

I believe it would be much nicer if you would use the 'Libgssglue'

package instead! Then the user can change GSS-API library at run-time.

Read about this work here:

https://blog.josefsson.org/2022/07/14/towards-pluggable-gss-api-modules/

/Simon

-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCYu50dxQcc2ltb25Aam9z

ZWZzc29uLm9yZwAKCRBRcisI/kdForNnAP9MOtpwjj4+yezNeoabfkd/kXE++9WI

+aPryFiQpET3OwEAzO+EtEVv+T2X62Sr2ltW7gIWjLwMYwr7fN0SIwFa1wo=

=oLO3

-----END PGP SIGNATURE-----

Maxim Cournoyer wrote on 10 Aug 2022 02:48

Recipients:(name . Simon Josefsson)(address . simon@josefsson.org)

Message-ID:877d3gorek.fsf@gmail.com

Hi Simon,

Simon Josefsson <simon@josefsson.org> writes:

Toggle quote (51 lines)> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Hello,
>>
>> I'd like to inquire about the development status of GSS? Has it left the
>> beta status? Are bugs still being fixed? Is there any known or presumed
>> security issues when using GSS rather than its more mainstream
>> implementation in MIT Kerberos?
>>
>> I'm asking because the GNU Guix project is considering a switch from GNU
>> GSS to MIT krb5 for security reasons [0], given that no new releases have
>> been made since 2014.
>>
>> Thank you,
>>
>> Maxim Cournoyer
>>
>> [0]  http://issues.guix.info/issue/34632
>
> Hi Maxim,
>
> Sorry for the slow response, which may in part be an answer to your
> question.  However I have just released GNU GSS version 1.0.4 to refresh
> the project, and have setup CI/CD checking of it to pave the road for
> future improvements.  To my knowledge there are only two major missing
> features:
>
>   1) Missing gss_wrap() AES functionality.  This prevents SASL GSS-API
>      to complete on modern machines.  Shishi supports AES and GSSLib
>      supports it for GSS_Init_sec_context etc but not GSS_wrap.
>
>   2) Shishi doesn't use the same ccache/keytab files as MIT Kerberos and
>      Heimdal.
>
> I hope to complete 1) in the future.  For 2), fixing it would be a GNU
> Shishi feature that should be simple to resolve -- it ships with tools
> ccache2shishi and keytab2shishi to convert the files, but that should be
> done automatically internally by the library instead.
>
> Indeed getting these enrolled in the OSS Fuzz project would be a great
> contribution.  My primary goal is to do a new release of GNU Shishi and
> improve the CI/CD integration checks to have good confidence in future
> changes.
>
> Regarding what 'gsasl' and 'curl' should be linked against in GNU Guix,
> I believe it would be much nicer if you would use the 'Libgssglue'
> package instead!  Then the user can change GSS-API library at run-time.
> Read about this work here:
>
> https://blog.josefsson.org/2022/07/14/towards-pluggable-gss-api-modules/

Thank you for this update! I'm happy to read you are picking up

maintenance of GSS. The libgssglue is interesting... I'll have to read

about it to know how it's intended to be used.

Thanks, and long live GNU GSS!

Maxim

Your comment

This issue is archived.

To comment on this conversation send an email to 34632@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 34632

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date