Oauth 2.0

[root]

I saw a reference to 7.x version of Fetchmail from GitHub, but now
I can't find it. I am pretty sure the Slackware packages for
fetchmail do not support the new authorization method. Is it
likely that a Slackware package will appear before the new OAuth
takes effect?

[Ben Collver]

Post by root
I saw a reference to 7.x version of Fetchmail from GitHub, but now
I can't find it. I am pretty sure the Slackware packages for
fetchmail do not support the new authorization method. Is it
likely that a Slackware package will appear before the new OAuth
takes effect?

I don't know the answer to your question, but in case you need other
options, Slackware's getmail package supports OAuth 2.0

[root]

Post by Ben Collver
I don't know the answer to your question, but in case you need other
options, Slackware's getmail package supports OAuth 2.0

Thanks, I will look into getmail.

[root]

Post by root

Post by Ben Collver
I don't know the answer to your question, but in case you need other
options, Slackware's getmail package supports OAuth 2.0

Thanks, I will look into getmail.

getmail doesn't seem to work for me. I think I remember that
I switched to fetchmail some time ago because getmail stopped
working.

This is the .getmailrc file I am using:

[retriever]
type = SimplePOP3Retriever
server = pop.gmail.com
username = MYNAME
password = MYPASS
port = 995
[destination]
type = Maildir
#type = Mboxrd
path = /var/spool/mail/root
#[other-destination-1]
#type = Mboxrd
#path = /var/spool/mail/root
#user = root
[filter-3]
type = Filter_external
path = /root/bin/mailfilter
allow_root_commands = 1
ignore_stderr=true
##arguments = ('--message-from-stdin', '--remove-all-but-attachment-types=text/plain,text/rfc822')
#user = root

I had been using Mboxrd. I switched to Maildir and had to create
a number of directories before getmail would run. It still reports
no mail even though I know mail is waiting for me.

Please help, I haven't done anything with mail in over a decade.

[#Paul]

Post by root
I saw a reference to 7.x version of Fetchmail from GitHub, but now
I can't find it. I am pretty sure the Slackware packages for
fetchmail do not support the new authorization method. Is it
likely that a Slackware package will appear before the new OAuth
takes effect?

FWIW, there's been some discussion of OAuth &etc on the fetchmail
mailing list recently.

#Paul

[root]

Post by #Paul

Post by root
I saw a reference to 7.x version of Fetchmail from GitHub, but now
I can't find it. I am pretty sure the Slackware packages for
fetchmail do not support the new authorization method. Is it
likely that a Slackware package will appear before the new OAuth
takes effect?

FWIW, there's been some discussion of OAuth &etc on the fetchmail
mailing list recently.
#Paul

There is a new version of fetchmail:
fetchmail-git-156d9cf5813241706bc7cffb17aaaae3a3fa8226.zip

but it will not make because:

configure: error: Your SSL library is too old and does not support TLS v1.3. Upgrade.


So I tried updating and upgrading all my packages for 14.2 and
I still do not get the required TLS version.

For now I am dead in the water.

[Henrik Carlqvist]

So I tried updating and upgrading all my packages for 14.2 and I still
do not get the required TLS version.
For now I am dead in the water.

Even though Slackware 14.2 with its age of almost 6 years is still being
maintained, it only gives security updates to packages where the upstream
providers gives releases which still works with Slackware 14.2. A number
of packages like mozilla-firefox no longer comes with updates for 14.2.

A few weeks ago there was a security update for 14.2 were version 1.0.2u
of openssl was rebuilt. At the same time 15.0 was upgraded to version
1.1.1n. Since version 1.1.1 openssl is supposed to have support for TLS
v1.3.

Version 1.0.2 of openssl is now EOL and maybe there is some reason that
14.2 sticks to that version. If you are lucky you might be able to
compile some 1.1.1 version yourself and get it working on 14.2.
Otherwise, if you really need TLS v1.3, you might need to upgrade your
Slackware installation to 15.0.

m v h Henrik

[root]

Post by Henrik Carlqvist
Even though Slackware 14.2 with its age of almost 6 years is still being
maintained, it only gives security updates to packages where the upstream
providers gives releases which still works with Slackware 14.2. A number
of packages like mozilla-firefox no longer comes with updates for 14.2.
A few weeks ago there was a security update for 14.2 were version 1.0.2u
of openssl was rebuilt. At the same time 15.0 was upgraded to version
1.1.1n. Since version 1.1.1 openssl is supposed to have support for TLS
v1.3.
Version 1.0.2 of openssl is now EOL and maybe there is some reason that
14.2 sticks to that version. If you are lucky you might be able to
compile some 1.1.1 version yourself and get it working on 14.2.
Otherwise, if you really need TLS v1.3, you might need to upgrade your
Slackware installation to 15.0.
m v h Henrik

Thanks for responding Henrik. I came to the same conclusion and
am now trying out 15.0.

[Giovanni]

Post by root
Thanks for responding Henrik. I came to the same conclusion and
am now trying out 15.0.

Last week I started working on porting openssl-1.1.1n from 15.0 to 14.2
to get TLS 1.3 on 14.2

Using slackbuild from 15.0 the package compiles correctly but I haven't
yet installed and tested.

As soon as I'll have some spare time I'll will try to load it in my test
installation on virtualbox. I'm still confused on how to install the
new package. Any suggestion welcomed.

Ciao
Giovanni

[Ralph Spitzner]

Using slackbuild from 15.0 the package compiles correctly but I haven't yet installed and tested.
As soon as I'll have some spare time I'll will try to load it in my test installation on virtualbox.  I'm still confused on how to install the new package.  Any suggestion welcomed.

just try upgradepkg ?


-rasp

[Giovanni]

Post by Ralph Spitzner

Post by Giovanni
Using slackbuild from 15.0 the package compiles correctly but I
haven't yet installed and tested.
As soon as I'll have some spare time I'll will try to load it in my
test installation on virtualbox.  I'm still confused on how to install
the new package.  Any suggestion welcomed.

just try upgradepkg ?
    -rasp

Not a good idea, unless you relink every program using old libraries.
I need TLS 1.3 mainly for fetchmail that I upgraded to 6.4.27 but
compiled with openssl 1.0.2 and now I'd like to upgrade also openssl.

I need to understand if new and old version of openssl can be installed
at the same time.

Ciao
Giovanni

[Ralph Spitzner]

Post by Giovanni
Not a good idea, unless you relink every program using old libraries.
I need TLS 1.3 mainly for fetchmail that I upgraded to 6.4.27 but compiled with openssl 1.0.2 and now I'd like to upgrade also openssl.
I need to understand if new and old version of openssl can be installed at the same time.
Ciao
Giovanni

unless they've changed the api, old call should still be there, Ionly had problems the other way around..
(newer programs, older libraries)
of course there are programs which want to open a lisomething.x.y.so explicityly
so for testing you could just copy over the new .so's alongside the old ones, run ldconfig and see what program picks up which....
just a thaught...


-rasp

[Chris Vine]

On Thu, 5 May 2022 15:51:22 +0200

Post by Giovanni

Post by Ralph Spitzner

Post by Giovanni
Using slackbuild from 15.0 the package compiles correctly but I
haven't yet installed and tested.
As soon as I'll have some spare time I'll will try to load it in my
test installation on virtualbox.  I'm still confused on how to install
the new package.  Any suggestion welcomed.

just try upgradepkg ?
    -rasp

Not a good idea, unless you relink every program using old libraries.
I need TLS 1.3 mainly for fetchmail that I upgraded to 6.4.27 but
compiled with openssl 1.0.2 and now I'd like to upgrade also openssl.
I need to understand if new and old version of openssl can be installed
at the same time.

Some libraries do allow multiple versions of the same library to be
installed and linked to concurrently, as they mangle function names to
include the version number in the function name (icu4c is an example
of this), but most do not.

The problem you have is that if you have a binary which links directly
or (by virtue of linking with other libraries) indirectly to two
versions of a particular library such as openssl which reuses the same
function names, it is a matter of luck as to which function version the
linker in fact links up with. The result is that your binary is likely
to crash from time to time in puzzling ways.

I have no idea what the position is with openssl, but assuming it does
not mangle names you will need to ensure that no library that your
home-compiled fetchmail links with attempts to link with a different
version of openssl than openssl-1.1.

[Chris Vine]

On Thu, 5 May 2022 19:57:37 +0100

Post by Chris Vine
On Thu, 5 May 2022 15:51:22 +0200

Post by Giovanni
I need to understand if new and old version of openssl can be installed
at the same time.

Some libraries do allow multiple versions of the same library to bef
installed and linked to concurrently, as they mangle function names toe
include the version number in the function name (icu4c is an example
of this), but most do not.
The problem you have is that if you have a binary which links directly
or (by virtue of linking with other libraries) indirectly to two
versions of a particular library such as openssl which reuses the same
function names, it is a matter of luck as to which function version the
linker in fact links up with. The result is that your binary is likely
to crash from time to time in puzzling ways.
I have no idea what the position is with openssl, but assuming it does
not mangle names you will need to ensure that no library that your
home-compiled fetchmail links with attempts to link with a different
version of openssl than openssl-1.1.

By the way, the above answers the question you asked.

But there is a further point about how you compile fetchmail against
openssl-1.1 when you want to retain openssl-1.0 as your "system"
version. Probably the best way is to install openssl-1.1 in a
different prefix such as /opt/openssl-1.1, and when compiling fetchmail
set PKG_CONFIG_PATH to first look in /opt/openssl-1.1/lib64/pkgconfig
and set LD_LIBRARY_PATH to /opt/openssl-4.1/lib64. When running
fetchmail you would also need to set LD_LIBRARY_PATH, say by starting
fetchmail via a shell script.

[Henrik Carlqvist]

Probably the best way is to install openssl-1.1 in a different
prefix such as /opt/openssl-1.1, and when compiling fetchmail set
PKG_CONFIG_PATH to first look in /opt/openssl-1.1/lib64/pkgconfig and
set LD_LIBRARY_PATH to /opt/openssl-4.1/lib64. When running fetchmail
you would also need to set LD_LIBRARY_PATH, say by starting fetchmail
via a shell script.

Yes, that will probably be neccessary, on Slackware 14.2
"ldd /usr/bin/fetchmail" shows:

linux-vdso.so.1 (0x00007ffe78bc2000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f98e49ac000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f98e4791000)
libssl.so.1 => /lib64/libssl.so.1 (0x00007f98e451d000)
libcrypto.so.1 => /lib64/libcrypto.so.1 (0x00007f98e40c5000)
libc.so.6 => /lib64/libc.so.6 (0x00007f98e3cfc000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f98e3af7000)
/lib64/ld-linux-x86-64.so.2 (0x0000557b6be1a000)

So fetchmail is dynamically linked to /lib64/libssl.so.1 which is a
symbolic link to libssl.so.1.0.0 which comes from the openssl-1.0.2u
(which by the way was updated again just some day ago)

If you are lucky, fetchmail and other applications will work better out-
of-the box with the new 1.1 versions of the dynamic libraries from
openssl-1.1, but maybe something will break. If so, there is no better
suggestion than to install then newer version of openssl in another
prefix and recompile selected applications against the newer version.
Maybe you want to statically link those recompiled applications to avoid
the need to set LD_LIBRARY_PATH before running the recompiled
applications.

You will not be able to have both versions of openssl installed next to
each other in their ordinary directory structure as they probably both
want to use the symbolic link libssl.so.1 and they probably both want to
use the same header files in /usr/include/openssl.

regards Henrik