Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an authentication plugin to cyrus sasl for XOAUTH2 #108480

Closed
MartinPotier opened this issue Jan 5, 2021 · 8 comments · Fixed by #199985
Closed

Add an authentication plugin to cyrus sasl for XOAUTH2 #108480

MartinPotier opened this issue Jan 5, 2021 · 8 comments · Fixed by #199985

Comments

@MartinPotier
Copy link
Contributor

MartinPotier commented Jan 5, 2021

Add XOAUTH2 plugin to cyrus sasl suite of auth mechanisms
adding a plugin to cyrus_sasl

Let's add for example this plugin https://github.com/moriyoshi/cyrus-sasl-xoauth2 to the list of authentication mechanisms. One example use case is to allow mbsync (isync) to authenticate against outlook office365's IMAP server, or Google's.

As https://www.cyrusimap.org/sasl/sasl/developer/plugprog.html mentions:

All plugins should live in the same directory (generally /usr/lib/sasl2), which the glue code (that is, the interface layer that sits between the plugins and the application) scans when one of the init functions (sasl_server_init or sasl_client_init) is called.

So there's a trick to make the plugin auto-discovered, I can see some options:

  • “augment” the cyrus_sasl package with extra entries in the dev output (sort of clunky)
  • create a stable entry under /run/current-system/sw/lib to group all plugin libs

Metadata

@junyi-hou
Copy link

Second this. A simple mkDerivation cannot do the trick because cyrus-sasl-xoauth2 will look for /usr/lib/sasl2. Can we override this with ${cyrus-sasl}/lib/sasl2 using, say, a patch to the original package?

@junyi-hou
Copy link

junyi-hou commented Feb 2, 2021

In the meantime, I use the following hack to get xoauth2 plugin working for now:

  1. build a copy of cyrus_sasl since it is a dependency of xoauth2 plugin
  2. buildxoauth2 plugin (I use robn's sasl2-oauth plugin)
  3. add an overlay of cyrus_sasl with xoauth2 libraries symlinking to ${cyruss_sasl}/lib/sasl2:
self: super:
{
  cyrus_sasl = super.cyrus_sasl.overrideAttrs (div: rec {
    postInstall = ''
      for lib in ${oauth2Lib}/lib/sasl2/*; do
        ln -sf $lib $out/lib/sasl2/
      done
    '';
  });
}

This hack is not ideal (has to build a separate cyrus_sasl just for building xoauth2 library). But it gets the job done.

@jackmac92
Copy link

jackmac92 commented Jun 13, 2021

@junyi-hou do you have a link to a full setup? Or do you remember what are you using for oauth2Lib?

Link to @junyi-hou's setup

edit: remove question add link

@hhomar
Copy link
Contributor

hhomar commented May 2, 2022

cyrus sasl has a SASL_PATH environment variable for specifying a colon separated list of directories to search for plugins.

I don't know if this is the best way, but I've put the following in an overlay, and other than having to compile the cyrus-sasl-xoauth2 plugin, nothing else needs to be build:

  isync-oauth2 = super.buildEnv {
    name = "isync-oauth2";
    paths = [ super.isync ];
    pathsToLink = [ "/bin" ];
    nativeBuildInputs = [ super.makeWrapper ];
    postBuild = ''
      wrapProgram "$out/bin/mbsync" \
        --prefix SASL_PATH : "${super.cyrus_sasl.out.outPath}/lib/sasl2:${self.cyrus_sasl_xoauth2}/lib/sasl2"
    '';
  };

@matshch
Copy link
Contributor

matshch commented Jun 12, 2022

SASL_PATH looks to be working, I've used it to glue in XOAUTH2 plugin from libkgapi to kdepim-runtime, so KMail can receive mail from Gmail:

(libsForQt5.kdepim-runtime.overrideAttrs (finalAttr: previousAttrs: {
  qtWrapperArgs = [ ''--prefix SASL_PATH : ${pkgs.cyrus_sasl}/lib/sasl2:${pkgs.libsForQt5.libkgapi}/lib/sasl2'' ];
}))

It probably should propagate somehow from buildInputs.

@croissong
Copy link
Contributor

Here's the full overlay i use, based on the example above, including compilation of moriyoshi/cyrus-sasl-xoauth2:

(self: super: {
    cyrus-sasl-xoauth2 = super.pkgs.stdenv.mkDerivation rec {
      pname = "cyrus-sasl-xoauth2";
      version = "master";

      src = super.pkgs.fetchFromGitHub {
        owner = "moriyoshi";
        repo = "cyrus-sasl-xoauth2";
        rev = "master";
        sha256 = "sha256-OlmHuME9idC0fWMzT4kY+YQ43GGch53snDq3w5v/cgk=";
      };

      nativeBuildInputs = [super.pkg-config super.automake super.autoconf super.libtool];
      propagatedBuildInputs = [super.cyrus_sasl];

      buildPhase = ''
        ./autogen.sh
        ./configure
      '';

      installPhase = ''
        make DESTDIR="$out" install
      '';

      meta = with super.pkgs.lib; {
        homepage = "https://github.com/moriyoshi/cyrus-sasl-xoauth2";
        description = "XOAUTH2 mechanism plugin for cyrus-sasl";
      };
    };

    # https://github.com/NixOS/nixpkgs/issues/108480#issuecomment-1115108802
    isync-oauth2 = super.buildEnv {
      name = "isync-oauth2";
      paths = [super.isync];
      pathsToLink = ["/bin"];
      nativeBuildInputs = [super.makeWrapper];
      postBuild = ''
        wrapProgram "$out/bin/mbsync" \
          --prefix SASL_PATH : "${super.cyrus_sasl.out.outPath}/lib/sasl2:${self.cyrus-sasl-xoauth2}/usr/lib/sasl2"
      '';
    };
  })

In combination with programs.mbsync.package = pkgs.isync-oauth2; this enables XOAUTH2 in mbsync!

@jackmac92
Copy link

Hey I've been following this issue for a while but don't really see how I'd setup my config to use xoauth2 with the updates from #199985

Are there any docs/examples on using the new setup? Or another issue to follow?

@wentasah
Copy link
Contributor

I use this in a wrapper of isync/mbsync, as can be seen in my configuration.

It would be good idea to integrate this directly into isync expression, as withCyrusSaslXoauth2 parameter. I'll look at that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants