fetchmail-users — User questions and discussion

Re: [Fetchmail-users] KeyError: 'refresh_token' error in fetchmail-oauth2

[Marco G. <ga...@li...>]

Mandi! Kamil Jo??ca
  In chel di` si favelave...

> Have you tried add
[...]
> to config?

Yes. Same result...

-- 
  Stanno arrivando da lontano con il futuro nella mano
  sotto la pioggia					(A. Venditti)

Re: [Fetchmail-users] How to build a fetchmail 7 rpm on CentOS 7

[ckeader <ck...@di...>]

 
> However, linking something against static libraries is bad practice and
> you cannot update fetchmail and OpenSSL independently, and is
> unnecessary. Just install your local openssl 3 into some other
> directory, tie your fetchmail RPM to it by some file path, and make
> fetchmail use that with the ways shown here on the list before.

That's correct - however, this is the only method I can use to wrap
everything into a single rpm. Ideally I like to see every single file on
the OS partitions as part of the package.

> Also, there is no such thing as fetchmail-7.0.0-alpha10 currently (no
> tag, no release).

It gets created when you run make dist in a configured git clone :)

Re: [Fetchmail-users] How to build a fetchmail 7 rpm on CentOS 7

[Matthias A. <mat...@gm...>]

Am 06.04.22 um 00:59 schrieb ckeader via Fetchmail-users:
> HACK ALERT
>
> ...
> All going well, the build completes and prints the location of the resulting
> rpms. There should be three packages, binary for your %arch, SRPM and
> debuginfo. The included fetchmail binary is statically linked against
> openssl 3.x. It is completely untested and may not even work. In particular,
> the ephemeral locations of SSL engines and modules are built into the openssl
> libraries, and I do not know if fetchmail tries to load any of them in
> operation; which will fail.

That depends on the system's configuration. Fetchmail by itself tries to
slurp the default X.509 trust store only.
Purpose is that is has something to verify server certificates.

fetchmail -V queries and prints the OPENSSLDIR so that there is some
anchor point where people should start looking for OpenSSL's *.cnf files.

However, linking something against static libraries is bad practice and
you cannot update fetchmail and OpenSSL independently, and is
unnecessary. Just install your local openssl 3 into some other
directory, tie your fetchmail RPM to it by some file path, and make
fetchmail use that with the ways shown here on the list before.

Also, there is no such thing as fetchmail-7.0.0-alpha10 currently (no
tag, no release).

[Fetchmail-users] How to build a fetchmail 7 rpm on CentOS 7

[ckeader <ck...@di...>]

HACK ALERT

Objective: build a fetchmail 7 alpha rpm on CentOS/RHEL 7.
Why? Some people prefer packages to installing from source on some types
of systems.

Create a fetchmail 7 alpha distribution archive
===============================================

Follow instructions to clone the fetchmal git repo, "next" branch.
Configure and "make dist", which should result in an archive named
fetchmail-7.0.0-alpha10.tar.xz or newer.

Unpack this archive, rename the directory to fetchmail-7.0.0, and repack as
fetchmail-7.0.0.tar.xz. This simplifies the spec file somewhat.

OpenSSL 3.x
===========

Download openssl-3.x source archive and signature file.

CentOS 7 fetchmail SRPM
=======================

Download and install the latest CentOS 7 fetchmail SRPM. Assuming all files
are copied into your builduser's ~/rpmbuild, copy the fetchmail-7.x and
openssl-3.x files from above into the SOURCES directory.

RPM SPEC file
=============

In the SPECS directory, take a backup of fetchmail.spec and apply the attached
patch. I found that fetchmail's configure gave different results for openssl
when built with and without mock, the sed expression in the %build section
tries to cover all bases.

Build
=====

Build it. With mock,

 rpmbuild -bs fetchmail.spec
 cd ../SRPMS
 mock fetchmail-7.0.0-1.el7.src.rpm

 otherwise just use rpmbuild -ba.

Grab a coffee, the openssl build will take a while.

All going well, the build completes and prints the location of the resulting
rpms. There should be three packages, binary for your %arch, SRPM and
debuginfo. The included fetchmail binary is statically linked against
openssl 3.x. It is completely untested and may not even work. In particular,
the ephemeral locations of SSL engines and modules are built into the openssl
libraries, and I do not know if fetchmail tries to load any of them in
operation; which will fail.

$ ldd fetchmail |grep -E "ssl|crypto"
	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f7c78b8c000)
$ ./fetchmail -V
This is fetchmail release 7.0.0-alpha10+GSS+RPA+NTLM+SDPS+SSL-SSLv2-SSLv3+HESIOD+NLS+KRB5.
Compiled with SSL library 0x30000020 "OpenSSL 3.0.2 15 Mar 2022"
Run-time uses SSL library 0x30000020 "OpenSSL 3.0.2 15 Mar 2022"
OpenSSL: OPENSSLDIR: "/etc/pki/tls"
Engines: ENGINESDIR: "/tmp/local/lib64/engines-3"

Copyright (C) 2002, 2003 Eric S. Raymond
Copyright (C) 2004 Matthias Andree, Eric S. Raymond,
                   Robert M. Funk, Graham Wilson
Copyright (C) 2005 - 2012 Sunil Shetye
Copyright (C) 2005 - 2021 Matthias Andree
Fetchmail comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. For details,
please see the file COPYING in the source or documentation directory.
This product includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit. (http://www.openssl.org/)

Linux centos7-buildvm 3.10.0-1160.59.1.el7.x86_64 #1 SMP Wed Feb 23 16:47:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Taking options from command line
No mailservers set up -- perhaps ~/.fetchmailrc is missing?
[builder@c7x64 bin]$ 

For comparison, on a different type of system:

$ ldd `which fetchmail` | grep -E "ssl|crypto"
	libssl.so.1.1 => /usr/lib64/libssl.so.1.1 (0x00007fcee0da5000)
	libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007fcee0ae6000)
$

Re: [Fetchmail-users] OAUTH2 Dilemma

[Matthias A. <mat...@gm...>]

Am 04.04.22 um 12:54 schrieb ckeader via Fetchmail-users:
> Matthias Andree writes:
>> Am 27.03.22 um 22:07 schrieb ckeader via Fetchmail-users:
>>>> You can install the latest OpenSSL 3.0.x to a separate directory,
>>>> WARNING UNTESTED because I do not have CentOS 7,
>>>> but somewhere along the lines of but maybe needs tweaking:
>>>> unpack OpenSSL 3.0.x, then
>>>> ./config --prefix /opt/openssl3 --openssldir=/usr/lib64
>>>> -Wl,-rpath=/opt/openssl3/lib
>>>> -- and then point your fetchmail 7 alpha build there to use it, with
>>>> ./configure --with-ssl=/opt/openssl3
>>>>
>>>> The additional burden on you will then be to watch future OpenSSL 3.0.x
>>>> releases and upgrade your /opt/openssl3 should security fixes become
>>>> necessary in some future OpenSSL version, so take notes of what worked
>>>> for you if you had to tweak things.
>>> I can improve on that ... does this list server strip attachments?
>> Yes, some attachment types, and also bigger attachments. The mailing
>> list is not intended to distribute larger or binary attachments. Smaller
>> plain text attachments (few kBytes, so your .spec file or something)
>> should work, for something bigger, file them through fetchmail's
>> ticketing systems on SourceForge or GitLab please and mail the pointer.
>>> I've been rolling my own fetchmail 6.4 rpm on CentOS 6, statically compiled against openssl 1.1.1. The method might work on CentOS 7 with fetchmail 7 and openssl 3.0 in a similar way. Obviously, one should update when either fetchmail or openssl release a new version.
> My method doea not work for fetchmail 7 alpha. It looks like it does not support openssl 3.x yet.

Try cloning from Git and switch to the "next" branch. Read README.git
and install necessary maintainer tools. Also note that I do not support
building future releases on older systems even if they are under
long-term support.

I roll alpha tarballs very infrequently, however, I believe Git commit
cfa4ebceb fixes this up. All the other parts should be ready for OpenSSL 3.

https://gitlab.com/fetchmail/fetchmail/-/commit/cfa4ebceb8aa80feaeb649d44774e6b48e9cf4f9
- under [Options v] top right, there are ways to "Download" a patch in
two forms, or just manually remove the lines in your socket.c shown on
red background.

> /tmp/fetchmail-7.0.0-alpha9/socket.c:997: undefined reference to `SSL_load_error_strings'
> /tmp/fetchmail-7.0.0-alpha9/socket.c:998: undefined reference to `SSL_library_init'
> /tmp/fetchmail-7.0.0-alpha9/socket.c:999: undefined reference to `OpenSSL_add_all_algorithms'
> /tmp/fetchmail-7.0.0-alpha9/socket.c:1000: undefined reference to `SSLeay'
>
> The rpm I have right now is really only suitable for a static openssl that gets built on the fly. I can get that part working after a fashion by manually modifying the fetchmail Makefile after configure.

Re: [Fetchmail-users] OAUTH2 Dilemma (getting off topic)

[Dennis P. <da...@be...>]

On 4/1/2022 12:43 PM, Matthias Andree wrote:
> Am 30.03.22 um 19:08 schrieb Dennis Putnam:
>> Hi Matthias,
>>
>> Openssl 3 seemed to install correctly or at least it passed 'make
>> test'. However, I am not able to run it as I get this:
>>
>> >/opt/openssl3/bin/openssl version
>> /opt/openssl3/bin/openssl: error while loading shared libraries:
>> libssl.so.3: cannot open shared object file: No such file or directory
>>
>> It appears a library did not get built or put in the right place.
>> Unless I am missing a prereq but then I would have expected the test
>> to have failed.
>>
> The cause is rather that the RPATH has not made it into the output
> files, so the run-time linker does not know where to find libssl.so.3.
> You can use readelf -d or objdump -p + some ELF executable to figure,
> example below.
>
> So, sorry for the confusion. I have just taken the time to tweak for
> Fedora 35, and I figured that the -Wl,-rpath isn't trivially passed
> through, but requires a specific syntax (see NOTES-UNIX.md) to be
> recognized and not silently ignored.
>
> For Fedora Linux 35 on amd64, I also figured that the default output
> directory would be /opt/openssl3/lib64 (mind the 64).
>
>> $ readelf -d /opt/openssl3/bin/openssl
>>
>> Dynamic section at offset 0xc1da8 contains 27 entries:
>>   Tag        Type                         Name/Value
>>  0x0000000000000001 (NEEDED)             Shared library: [libssl.so.3]
>>  0x0000000000000001 (NEEDED)             Shared library: 
>> [libcrypto.so.3]
>>  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>>  0x000000000000001d (RUNPATH)            Library runpath:
>> [/opt/openssl3/lib64]
>> ...
>
>
> On Fedora 35, I received a successful build and working install with
> (note comma, not assignment/equals, between -Wl,-rpath and the path):
>
>> mkdir _build
>> cd _build
>> ../config --prefix=/opt/openssl3 -Wl,-rpath,/opt/openssl3/lib64
>> --openssldir=/etc/pki/tls
>> make -j8
>> sudo make -j8 install
> adjust -j8 to -j followed by the number of availble CPU threads.
>
>
> This, for me on Fedora 35, yields an openssl that works, with
>
> /opt/openssl3/bin/openssl version -a
> /opt/openssl3/bin/openssl s_client -connect fetchmail.sourceforge.io:443
> -CAfile /etc/ssl/certs/ca-bundle.trust.crt -verify 5
>
> HTH.
>
> Regards,
> Matthias
>
>
>
Hi Matthias,

Thanks. The 'lib64' made the difference. I have a working openssl3 now.

On to fetchmail 7.

Re: [Fetchmail-users] OAUTH2 Dilemma

[ckeader <ck...@di...>]

Matthias Andree writes:
> Am 27.03.22 um 22:07 schrieb ckeader via Fetchmail-users:
> >> You can install the latest OpenSSL 3.0.x to a separate directory,
> >> WARNING UNTESTED because I do not have CentOS 7,
> >> but somewhere along the lines of but maybe needs tweaking:
> >> unpack OpenSSL 3.0.x, then
> >> ./config --prefix /opt/openssl3 --openssldir=/usr/lib64
> >> -Wl,-rpath=/opt/openssl3/lib
> >> -- and then point your fetchmail 7 alpha build there to use it, with
> >> ./configure --with-ssl=/opt/openssl3
> >>
> >> The additional burden on you will then be to watch future OpenSSL 3.0.x
> >> releases and upgrade your /opt/openssl3 should security fixes become
> >> necessary in some future OpenSSL version, so take notes of what worked
> >> for you if you had to tweak things.
> > I can improve on that ... does this list server strip attachments?
> Yes, some attachment types, and also bigger attachments. The mailing
> list is not intended to distribute larger or binary attachments. Smaller
> plain text attachments (few kBytes, so your .spec file or something)
> should work, for something bigger, file them through fetchmail's
> ticketing systems on SourceForge or GitLab please and mail the pointer.
> > I've been rolling my own fetchmail 6.4 rpm on CentOS 6, statically compiled against openssl 1.1.1. The method might work on CentOS 7 with fetchmail 7 and openssl 3.0 in a similar way. Obviously, one should update when either fetchmail or openssl release a new version.

My method doea not work for fetchmail 7 alpha. It looks like it does not support openssl 3.x yet.

/tmp/fetchmail-7.0.0-alpha9/socket.c:997: undefined reference to `SSL_load_error_strings'
/tmp/fetchmail-7.0.0-alpha9/socket.c:998: undefined reference to `SSL_library_init'
/tmp/fetchmail-7.0.0-alpha9/socket.c:999: undefined reference to `OpenSSL_add_all_algorithms'
/tmp/fetchmail-7.0.0-alpha9/socket.c:1000: undefined reference to `SSLeay'

The rpm I have right now is really only suitable for a static openssl that gets built on the fly. I can get that part working after a fashion by manually modifying the fetchmail Makefile after configure.

Re: [Fetchmail-users] KeyError: 'refresh_token' error in fetchmail-oauth2

[Kamil J. <kj...@o2...>]

Marco Gaiarin <ga...@li...> writes:

> Mandi! Kamil Jo??ca
>   In chel di` si favelave...
>
>>> Someone have some clue?! Thanks.
>> Please paste your .oauth2.conf file
>> ... with client_id and client_secret mangled ...
>
>  irene@eraldo:~$ cat .oauth2.conf
>  client_id=<reducted>
>  client_secret=<reducted>
>  refresh_token_file=/home/irene/.oauth2.refresh
>  access_token_file=/home/irene/.oauth2.access
>  max_age_sec=1900
Have you tried add

--8<---------------cut here---------------start------------->8---
scope=https://mail.google.com/ https://www.googleapis.com/auth/carddav https://www.googleapis.com/auth/calendar
auth_url=https://accounts.google.com/o/oauth2/auth
token_url=https://www.googleapis.com/oauth2/v3/token
redirect_uri=urn:ietf:wg:oauth:2.0:oob
--8<---------------cut here---------------end--------------->8---

to config?
KJ

-- 
http://wolnelektury.pl/wesprzyj/teraz/

Re: [Fetchmail-users] KeyError: 'refresh_token' error in fetchmail-oauth2

[Marco G. <ga...@li...>]

Mandi! Kamil Jo??ca
  In chel di` si favelave...

>> Someone have some clue?! Thanks.
> Please paste your .oauth2.conf file
> ... with client_id and client_secret mangled ...

 irene@eraldo:~$ cat .oauth2.conf
 client_id=<reducted>
 client_secret=<reducted>
 refresh_token_file=/home/irene/.oauth2.refresh
 access_token_file=/home/irene/.oauth2.access
 max_age_sec=1900

-- 
  E quindi vado avanti e non mi svesto,
  dei panni che son solito portare			(F. Guccini)

Re: [Fetchmail-users] OAuth2 authenticator problem

[Robin A. <ro...@bi...>]

On Thu, 31 Mar 2022 15:08:21 +0200
"J.Edner" <fli...@te...> wrote:

> last year I've successfully got the Google OAuth2 authentication
> running and since then have set-up several accesses without any
> problem using Fetchmail 6.4.x with the OAuth2 patch.
> 
> https://gitlab.com/fetchmail/fetchmail/-/issues/27
> 
> http://mmogilvi.users.sourceforge.net/software/oauthbearer.html
> 
> I've documented the Google configuration steps with screenshots for
> my personal use in German language. If you want I can send you that
> pdf file so that you can try to get your account configured correctly.
> (Translating the text shouldn't be the problem thanks to Google 
> Translator ;-)

Juergen-
Thanks, that would be very helpful. Registering with Google was very
confusing!

Cheers
Robin
-- 
----------------------------------------------------------------------
Robin Atwood.

"Ship me somewheres east of Suez, where the best is like the worst,
 Where there ain't no Ten Commandments an' a man can raise a thirst"
         from "Mandalay" by Rudyard Kipling
----------------------------------------------------------------------

Re: [Fetchmail-users] OAUTH2 Dilemma (getting off topic)

[Matthias A. <mat...@gm...>]

Am 30.03.22 um 19:08 schrieb Dennis Putnam:
> Hi Matthias,
>
> Openssl 3 seemed to install correctly or at least it passed 'make
> test'. However, I am not able to run it as I get this:
>
> >/opt/openssl3/bin/openssl version
> /opt/openssl3/bin/openssl: error while loading shared libraries:
> libssl.so.3: cannot open shared object file: No such file or directory
>
> It appears a library did not get built or put in the right place.
> Unless I am missing a prereq but then I would have expected the test
> to have failed.
>
The cause is rather that the RPATH has not made it into the output
files, so the run-time linker does not know where to find libssl.so.3.
You can use readelf -d or objdump -p + some ELF executable to figure,
example below.

So, sorry for the confusion. I have just taken the time to tweak for
Fedora 35, and I figured that the -Wl,-rpath isn't trivially passed
through, but requires a specific syntax (see NOTES-UNIX.md) to be
recognized and not silently ignored.

For Fedora Linux 35 on amd64, I also figured that the default output
directory would be /opt/openssl3/lib64 (mind the 64).

> $ readelf -d /opt/openssl3/bin/openssl
>
> Dynamic section at offset 0xc1da8 contains 27 entries:
>   Tag        Type                         Name/Value
>  0x0000000000000001 (NEEDED)             Shared library: [libssl.so.3]
>  0x0000000000000001 (NEEDED)             Shared library: [libcrypto.so.3]
>  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>  0x000000000000001d (RUNPATH)            Library runpath:
> [/opt/openssl3/lib64]
> ...


On Fedora 35, I received a successful build and working install with
(note comma, not assignment/equals, between -Wl,-rpath and the path):

> mkdir _build
> cd _build
> ../config --prefix=/opt/openssl3 -Wl,-rpath,/opt/openssl3/lib64
> --openssldir=/etc/pki/tls
> make -j8
> sudo make -j8 install
adjust -j8 to -j followed by the number of availble CPU threads.


This, for me on Fedora 35, yields an openssl that works, with

/opt/openssl3/bin/openssl version -a
/opt/openssl3/bin/openssl s_client -connect fetchmail.sourceforge.io:443
-CAfile /etc/ssl/certs/ca-bundle.trust.crt -verify 5

HTH.

Regards,
Matthias

Re: [Fetchmail-users] OAUTH2 Dilemma

[Matthias A. <mat...@gm...>]

Am 27.03.22 um 22:07 schrieb ckeader via Fetchmail-users:
>> You can install the latest OpenSSL 3.0.x to a separate directory,
>> WARNING UNTESTED because I do not have CentOS 7,
>> but somewhere along the lines of but maybe needs tweaking:
>> unpack OpenSSL 3.0.x, then
>> ./config --prefix /opt/openssl3 --openssldir=/usr/lib64
>> -Wl,-rpath=/opt/openssl3/lib
>> -- and then point your fetchmail 7 alpha build there to use it, with
>> ./configure --with-ssl=/opt/openssl3
>>
>> The additional burden on you will then be to watch future OpenSSL 3.0.x
>> releases and upgrade your /opt/openssl3 should security fixes become
>> necessary in some future OpenSSL version, so take notes of what worked
>> for you if you had to tweak things.
> I can improve on that ... does this list server strip attachments?
Yes, some attachment types, and also bigger attachments. The mailing
list is not intended to distribute larger or binary attachments. Smaller
plain text attachments (few kBytes, so your .spec file or something)
should work, for something bigger, file them through fetchmail's
ticketing systems on SourceForge or GitLab please and mail the pointer.
> I've been rolling my own fetchmail 6.4 rpm on CentOS 6, statically compiled against openssl 1.1.1. The method might work on CentOS 7 with fetchmail 7 and openssl 3.0 in a similar way. Obviously, one should update when either fetchmail or openssl release a new version.

Re: [Fetchmail-users] OAUTH2 Dilemma (getting off topic)

[Dennis P. <da...@be...>]

On 3/30/2022 7:00 PM, ckeader via Fetchmail-users wrote:
>> Openssl 3 seemed to install correctly or at least it passed 'make test'.
>> However, I am not able to run it as I get this:
>>
>>   >/opt/openssl3/bin/openssl version
>> /opt/openssl3/bin/openssl: error while loading shared libraries:
>> libssl.so.3: cannot open shared object file: No such file or directory
>>
>> It appears a library did not get built or put in the right place. Unless
>> I am missing a prereq but then I would have expected the test to have
>> failed.
> As Matthias showed in an earlier message, you need to add -Wl,-rpath=/opt/openssl3/lib to the openssl3 configure options. That should get the above to work.
>
> I was curious and tried to build the latest alpha against openssl 3.0.2, but it fails at linker stage due to several symbols in socket.c not being found. As far as I've traced that (gcc -E -dD), it happens because OPENSSL_NO_DEPRECATED_1_1_0 is defined during the compile. E.g one of those functions is OpenSSL_add_ssl_algorithms(), and the compiler duly warns about implicit function declarations (cf. openssl/ssl.h near line 1100,
>
> # ifndef OPENSSL_NO_DEPRECATED_1_1_0
> #  define OpenSSL_add_ssl_algorithms()   SSL_library_init()
> #  define SSLeay_add_ssl_algorithms()    SSL_library_init()
> # endif
>
> ), so I'm wondering if one should try openssl 1.1.1 instead.
>
> OTOH I did not build openssl with no-deprecated or --api=xxx, so not sure what's going on.
>
>
>
I used the parameters indicated by Matthias verbatim including adding 
the '='. I did not get any warnings during the make and the make test 
passed all.

Re: [Fetchmail-users] OAuth2 authenticator problem

[J.Edner <fli...@te...>]

Hello Robin,

>> I ran
>> oauth2 -c /path/to/oauth2Config.properties --obtain_refresh_token_file
>> again and now the logon proceeds. I will see how long it works, one
>> week seems to be the limit. If it happens again I will try publishing
>> my app to see if that helps.
> 
> Yes, exactly one week later fetchmail ran out of authenticators again.
> I "published" my Google app and ran the refresh command as above but I
> received a message saying my app didn't obey the rules. So I
> unpublished it and then the refresh procedure worked. For another week
> I assume. Time to think about a new email service.

last year I've successfully got the Google OAuth2 authentication running 
and since then have set-up several accesses without any problem using 
Fetchmail 6.4.x with the OAuth2 patch.

https://gitlab.com/fetchmail/fetchmail/-/issues/27

http://mmogilvi.users.sourceforge.net/software/oauthbearer.html

I've documented the Google configuration steps with screenshots for
my personal use in German language. If you want I can send you that
pdf file so that you can try to get your account configured correctly.
(Translating the text shouldn't be the problem thanks to Google 
Translator ;-)

Regards
Juergen

Re: [Fetchmail-users] OAUTH2 Dilemma (getting off topic)

[ckeader <ck...@di...>]

> Openssl 3 seemed to install correctly or at least it passed 'make test'. 
> However, I am not able to run it as I get this:
> 
>  >/opt/openssl3/bin/openssl version
> /opt/openssl3/bin/openssl: error while loading shared libraries: 
> libssl.so.3: cannot open shared object file: No such file or directory
> 
> It appears a library did not get built or put in the right place. Unless 
> I am missing a prereq but then I would have expected the test to have 
> failed.

As Matthias showed in an earlier message, you need to add -Wl,-rpath=/opt/openssl3/lib to the openssl3 configure options. That should get the above to work.

I was curious and tried to build the latest alpha against openssl 3.0.2, but it fails at linker stage due to several symbols in socket.c not being found. As far as I've traced that (gcc -E -dD), it happens because OPENSSL_NO_DEPRECATED_1_1_0 is defined during the compile. E.g one of those functions is OpenSSL_add_ssl_algorithms(), and the compiler duly warns about implicit function declarations (cf. openssl/ssl.h near line 1100,

# ifndef OPENSSL_NO_DEPRECATED_1_1_0
#  define OpenSSL_add_ssl_algorithms()   SSL_library_init()
#  define SSLeay_add_ssl_algorithms()    SSL_library_init()
# endif

), so I'm wondering if one should try openssl 1.1.1 instead.

OTOH I did not build openssl with no-deprecated or --api=xxx, so not sure what's going on.

Re: [Fetchmail-users] KeyError: 'refresh_token' error in fetchmail-oauth2

[Kamil J. <kj...@o2...>]

Kamil Jońca <kj...@op...> writes:

> Marco Gaiarin <ga...@li...> writes:
>
>>>> Stupid question:
>>>> Have you pasted url to your browser?
>>
>>> Sure! Pasted the URL on browser, get auth screen, auth, get the reply code,
>>> paste that on the terminal.
>>
>> Someone have some clue?! Thanks.
> Please paste your .oauth2.conf file

... with client_id and client_secret mangled ...
KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

Re: [Fetchmail-users] KeyError: 'refresh_token' error in fetchmail-oauth2

[Marco G. <ga...@li...>]

>> Stupid question:
>> Have you pasted url to your browser?

> Sure! Pasted the URL on browser, get auth screen, auth, get the reply code,
> paste that on the terminal.

Someone have some clue?! Thanks.

-- 
  Ho ancora la forza di non tirarmi indietro, [...]
  di far la conta degli amici andati e dire ``ci vediam più tardi''
							(F. Guccini)

Re: [Fetchmail-users] OAUTH2 Dilemma (getting off topic)

[Dennis P. <da...@be...>]

On 3/30/2022 3:51 AM, Matthias Andree wrote:
> Am 29.03.22 um 17:09 schrieb Dennis Putnam:
>> On 3/27/2022 7:42 AM, Matthias Andree wrote:
>>> Am 26.03.22 um 21:20 schrieb Dennis Putnam:
>>>> It appears Fetchmail 7 requires TLS 1.3. I am running CentOS 7 and the
>>>> support folks tell me that RedHat does not intend to add TLS 1.3 to
>>>> CentOS. I wonder if it will be added to RHEL? Anyway, that means I am
>>>> stuck using Fetchmail 6 for the foreseeable future. Before I go to the
>>>> trouble, do the OAUTH2 patches for Fetchmail 6 also require TLS 1.3?
>>>> TIA.
>>>>
>>> Dennis,
>>>
>>> that's a bit of a letdown although I understand that in a stable CentOS
>>> 7 series they don't want major changes, and TLS v1.3 in itself is one,
>>> so you are stuck between a rock and a hard place... but you can work
>>> yourself out of this.
>>>
>>> You can install the latest OpenSSL 3.0.x to a separate directory,
>>> WARNING UNTESTED because I do not have CentOS 7,
>>> but somewhere along the lines of but maybe needs tweaking:
>>> unpack OpenSSL 3.0.x, then
>>> ./config --prefix /opt/openssl3 --openssldir=/usr/lib64
>>> -Wl,-rpath=/opt/openssl3/lib
>>> -- and then point your fetchmail 7 alpha build there to use it, with
>>> ./configure --with-ssl=/opt/openssl3
>>>
>>> The additional burden on you will then be to watch future OpenSSL 3.0.x
>>> releases and upgrade your /opt/openssl3 should security fixes become
>>> necessary in some future OpenSSL version, so take notes of what worked
>>> for you if you had to tweak things.
>>>
>>> Hope that helps.
>>> Matthias
>>>
>>>
>>
>> Hi Matthias,
>>
>> Quick question about --openssldir=/usr/lib64. Isn't that where openssl
>> 2 also lives? Won't that result in either overwriting or a conflict?
>
> Hi Dennis,
>
> First, I should say that it is to be --prefix=/opt/openssl3 (the =
> matters). Sorry about that.
>
> Then, about the openssldir, it seems that OpenSSL 3.0.2 would only
> install "*.cnf.dist" files (for ct_log_list.cnf and openssl.cnf) and
> then copy them to the real "*.cnf" if missing or otherwise let them
> alone. Also check if it's right for you.
> The plan is to share existing configuration so the certificate bundle
> and other trust stores are shared.
> Note I adapted the above in a web reference to CentOS, but I don't have
> CentOS myself; for Fedora Linux and I think on the Debian-based distros
> (including Ubuntu and derivatives) too, I would have to use
> --openssldir=/etc/pki/tls instead.
>
> Regards,
> Matthias
>
>
Hi Matthias,

Openssl 3 seemed to install correctly or at least it passed 'make test'. 
However, I am not able to run it as I get this:

 >/opt/openssl3/bin/openssl version
/opt/openssl3/bin/openssl: error while loading shared libraries: 
libssl.so.3: cannot open shared object file: No such file or directory

It appears a library did not get built or put in the right place. Unless 
I am missing a prereq but then I would have expected the test to have 
failed.

Re: [Fetchmail-users] OAUTH2 Dilemma

[Andrew C A. <fet...@ai...>]

On Wed, 30 Mar 2022, Matthias Andree wrote:

> Note I adapted the above in a web reference to CentOS, but I don't have
> CentOS myself; for Fedora Linux and I think on the Debian-based distros
> (including Ubuntu and derivatives) too, I would have to use
> --openssldir=/etc/pki/tls instead.

CentOS is likely to be the same as Fedora.
/etc/pki/tls was right for CentOS 6.

-- 
Andrew C. Aitchison					Kendal, UK
 			an...@ai...

Re: [Fetchmail-users] OAUTH2 Dilemma

[Matthias A. <mat...@gm...>]

Am 29.03.22 um 17:09 schrieb Dennis Putnam:
> On 3/27/2022 7:42 AM, Matthias Andree wrote:
>> Am 26.03.22 um 21:20 schrieb Dennis Putnam:
>>> It appears Fetchmail 7 requires TLS 1.3. I am running CentOS 7 and the
>>> support folks tell me that RedHat does not intend to add TLS 1.3 to
>>> CentOS. I wonder if it will be added to RHEL? Anyway, that means I am
>>> stuck using Fetchmail 6 for the foreseeable future. Before I go to the
>>> trouble, do the OAUTH2 patches for Fetchmail 6 also require TLS 1.3?
>>> TIA.
>>>
>> Dennis,
>>
>> that's a bit of a letdown although I understand that in a stable CentOS
>> 7 series they don't want major changes, and TLS v1.3 in itself is one,
>> so you are stuck between a rock and a hard place... but you can work
>> yourself out of this.
>>
>> You can install the latest OpenSSL 3.0.x to a separate directory,
>> WARNING UNTESTED because I do not have CentOS 7,
>> but somewhere along the lines of but maybe needs tweaking:
>> unpack OpenSSL 3.0.x, then
>> ./config --prefix /opt/openssl3 --openssldir=/usr/lib64
>> -Wl,-rpath=/opt/openssl3/lib
>> -- and then point your fetchmail 7 alpha build there to use it, with
>> ./configure --with-ssl=/opt/openssl3
>>
>> The additional burden on you will then be to watch future OpenSSL 3.0.x
>> releases and upgrade your /opt/openssl3 should security fixes become
>> necessary in some future OpenSSL version, so take notes of what worked
>> for you if you had to tweak things.
>>
>> Hope that helps.
>> Matthias
>>
>>
>
> Hi Matthias,
>
> Quick question about --openssldir=/usr/lib64. Isn't that where openssl
> 2 also lives? Won't that result in either overwriting or a conflict?

Hi Dennis,

First, I should say that it is to be --prefix=/opt/openssl3 (the =
matters). Sorry about that.

Then, about the openssldir, it seems that OpenSSL 3.0.2 would only
install "*.cnf.dist" files (for ct_log_list.cnf and openssl.cnf) and
then copy them to the real "*.cnf" if missing or otherwise let them
alone. Also check if it's right for you.
The plan is to share existing configuration so the certificate bundle
and other trust stores are shared.
Note I adapted the above in a web reference to CentOS, but I don't have
CentOS myself; for Fedora Linux and I think on the Debian-based distros
(including Ubuntu and derivatives) too, I would have to use
--openssldir=/etc/pki/tls instead.

Regards,
Matthias

Re: [Fetchmail-users] OAUTH2 Dilemma

[Dennis P. <da...@be...>]

On 3/27/2022 7:42 AM, Matthias Andree wrote:
> Am 26.03.22 um 21:20 schrieb Dennis Putnam:
>> It appears Fetchmail 7 requires TLS 1.3. I am running CentOS 7 and the
>> support folks tell me that RedHat does not intend to add TLS 1.3 to
>> CentOS. I wonder if it will be added to RHEL? Anyway, that means I am
>> stuck using Fetchmail 6 for the foreseeable future. Before I go to the
>> trouble, do the OAUTH2 patches for Fetchmail 6 also require TLS 1.3? 
>> TIA.
>>
> Dennis,
>
> that's a bit of a letdown although I understand that in a stable CentOS
> 7 series they don't want major changes, and TLS v1.3 in itself is one,
> so you are stuck between a rock and a hard place... but you can work
> yourself out of this.
>
> You can install the latest OpenSSL 3.0.x to a separate directory,
> WARNING UNTESTED because I do not have CentOS 7,
> but somewhere along the lines of but maybe needs tweaking:
> unpack OpenSSL 3.0.x, then
> ./config --prefix /opt/openssl3 --openssldir=/usr/lib64
> -Wl,-rpath=/opt/openssl3/lib
> -- and then point your fetchmail 7 alpha build there to use it, with
> ./configure --with-ssl=/opt/openssl3
>
> The additional burden on you will then be to watch future OpenSSL 3.0.x
> releases and upgrade your /opt/openssl3 should security fixes become
> necessary in some future OpenSSL version, so take notes of what worked
> for you if you had to tweak things.
>
> Hope that helps.
> Matthias
>
>

Hi Matthias,

Quick question about --openssldir=/usr/lib64. Isn't that where openssl 2 
also lives? Won't that result in either overwriting or a conflict?

Re: [Fetchmail-users] OAuth2 authenticator problem

[Robin A. <ro...@bi...>]

On Wed, 23 Mar 2022 21:00:01 +0700
Robin Atwood <ro...@bi...> wrote:
> > That's a sign that you had left authentication set to automatic and
> > the XOAUTH2 or OAUTHBEARER authentication method started failing
> > with your server at some point. Re-obtaining a new token with the
> > script may fix it, else running fetchmail in verbose mode (-v or -v
> > -v) may give you sufficient information to pinpoint the failure.  
> 
> I ran 
> oauth2 -c /path/to/oauth2Config.properties --obtain_refresh_token_file
> again and now the logon proceeds. I will see how long it works, one
> week seems to be the limit. If it happens again I will try publishing
> my app to see if that helps.

Yes, exactly one week later fetchmail ran out of authenticators again.
I "published" my Google app and ran the refresh command as above but I
received a message saying my app didn't obey the rules. So I
unpublished it and then the refresh procedure worked. For another week
I assume. Time to think about a new email service.

Robin
-- 
----------------------------------------------------------------------
Robin Atwood.

"Ship me somewheres east of Suez, where the best is like the worst,
 Where there ain't no Ten Commandments an' a man can raise a thirst"
         from "Mandalay" by Rudyard Kipling
----------------------------------------------------------------------

Re: [Fetchmail-users] KeyError: 'refresh_token' error in fetchmail-oauth2

[Marco G. <ga...@li...>]

Mandi! Kamil Jo??ca
  In chel di` si favelave...

> Stupid question:
> Have you pasted url to your browser?

Sure! Pasted the URL on browser, get auth screen, auth, get the reply code,
paste that on the terminal.

-- 
  Stanno arrivando da lontano con il futuro nella mano
  sotto la pioggia					(A. Venditti)

Re: [Fetchmail-users] KeyError: 'refresh_token' error in fetchmail-oauth2

[Kamil J. <kj...@o2...>]

Marco Gaiarin <ga...@li...> writes:

> I'm trying to configure oAuth2 access to GMail (consumer account); i think
> i've done correctly all the stuff needed, i open the browser page, auth,
> get the verification code, paste the verification code and:
>
>  irene@eraldo:~$ fetchmail-oauth2 -c .oauth2.conf --obtain_refresh_token_file
>  To authorize token, visit this url and follow the directions:
>    https://accounts.google.com/o/oauth2/auth?client_id=<reducted>
>  Enter verification code: <reducted>
>  Traceback (most recent call last):
>    File "/usr/bin/fetchmail-oauth2", line 567, in <module>
>      main(sys.argv)
>    File "/usr/bin/fetchmail-oauth2", line 503, in main
>      newRefTok = response['refresh_token']
>  KeyError: 'refresh_token'
>
> What i'm doing wrong?! Thanks.

Stupid question:
Have you pasted url to your browser?
--8<---------------cut here---------------start------------->8---
https://accounts.google.com/o/oauth2/auth?client_id=<reducted>
--8<---------------cut here---------------end--------------->8---
and then pasted reply ?

KJ

-- 
http://wolnelektury.pl/wesprzyj/teraz/

[Fetchmail-users] KeyError: 'refresh_token' error in fetchmail-oauth2

[Marco G. <ga...@li...>]

I'm trying to configure oAuth2 access to GMail (consumer account); i think
i've done correctly all the stuff needed, i open the browser page, auth,
get the verification code, paste the verification code and:

 irene@eraldo:~$ fetchmail-oauth2 -c .oauth2.conf --obtain_refresh_token_file
 To authorize token, visit this url and follow the directions:
   https://accounts.google.com/o/oauth2/auth?client_id=<reducted>
 Enter verification code: <reducted>
 Traceback (most recent call last):
   File "/usr/bin/fetchmail-oauth2", line 567, in <module>
     main(sys.argv)
   File "/usr/bin/fetchmail-oauth2", line 503, in main
     newRefTok = response['refresh_token']
 KeyError: 'refresh_token'

What i'm doing wrong?! Thanks.

-- 
  Solo una sana e consapevole libidine
  salva il giovane dagli SCOUT e dall'Azione Cattolica!
						(Zucchero, circa O;-)