Gmail vs upas

Gmail vs upas

[Steven Stallion]

All,

Is anyone still fetching Gmail these days? After bringing my old
fileserver back online I noticed that mail delivery seems to be
broken. Both getpop3 and upas/fs are complaining of invalid
certificates, which is leading me to think I need to make some updates
to the list of trusted certificates.

Any ideas?
Steve

Re: [9fans] Gmail vs upas

[Steve Simon]

hi,

i receive mail on plan9 so i dont use gmail.

you sure you didn't forget to install a new x509 thumbprint in /sys/lib/tls/mail?

-Steve

On 28 Nov 2019, at 3:40 pm, Steven Stallion <sstallion@gmail.com> wrote:
> 
> All,
> 
> Is anyone still fetching Gmail these days? After bringing my old
> fileserver back online I noticed that mail delivery seems to be
> broken. Both getpop3 and upas/fs are complaining of invalid
> certificates, which is leading me to think I need to make some updates
> to the list of trusted certificates.
> 
> Any ideas?
> Steve
> 
> ------------------------------------------
> 9fans: 9fans
> Permalink: https://9fans.topicbox.com/groups/9fans/Te20476748ab5e4ba-M73f7af9581dcefa8abad0ee2
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Gmail vs upas

[David du Colombier]

The TLS implementation on Plan 9 doesn't verify X.509 certificate chain,
so the certificate bundle isn't useful. It's only used by Go programs.

However, you need to add the server certificate fingerprint to /sys/lib/tls/mail,
as Steve Simon said.

-- 
David du Colombier

Re: [9fans] Gmail vs upas

[Steven Stallion]

Thanks guys. I suspect I'm about to regret my lack of time mucking
about with tls on plan9:

% upas/fs -f /imaps/imap.gmail.com/sstallion@gmail.com
upas/fs: opening /imaps/imap.gmail.com/sstallion@gmail.com:
imap.gmail.com/imaps:tlsClient: tls: local invalid x509/rsa
certificate

% cat /sys/lib/tls/mail
x509 sha1=f0d1545c78815ee782d479b48841f24afa217c35

To verify, I pulled the server fingerprint using OpenSSL:
% openssl s_client -connect imap.gmail.com:993 </dev/null 2>/dev/null
| openssl x509 -fingerprint -noout -in /dev/stdin
SHA1 Fingerprint=F0:D1:54:5C:78:81:5E:E7:82:D4:79:B4:88:41:F2:4A:FA:21:7C:35

Any other ideas?
Steve

On Thu, Nov 28, 2019 at 10:01 AM David du Colombier <0intro@gmail.com> wrote:
>
> The TLS implementation on Plan 9 doesn't verify X.509 certificate chain,
> so the certificate bundle isn't useful. It's only used by Go programs.
>
> However, you need to add the server certificate fingerprint to /sys/lib/tls/mail,
> as Steve Simon said.
>
> --
> David du Colombier
>
> ------------------------------------------
> 9fans: 9fans
> Permalink: https://9fans.topicbox.com/groups/9fans/Te20476748ab5e4ba-Mde55e25da902ed343e0215c8
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Gmail vs upas

[kvik]

Adding the fingerprint will work if you are lucky, once,
or maybe twice.

In my experience almost every new connection required
redoing the above -- which wasn't very fun so I ended
up forwarding gmail into a sub-mailbox under my control
and haven't looked back.

Working with their SMTP has the same problem, FWIW.

Re: [9fans] Gmail vs upas

[kvik]

Check /sys/log/mail for a fingerprint.

Re: [9fans] Gmail vs upas

[Steven Stallion]

Thanks - unfortunately it doesn't look like anything is being logged.
Interestingly enough, it looks like mail has been broken for quite a
while, this was the last log message recorded (the fileserver went
into storage in mid 2018):

gunge Aug 26 05:25:04 delivered stallion From stallion Wed Aug 26
05:25:04 CDT 2015 (stallion) 3055

Steve

On Thu, Nov 28, 2019 at 11:38 AM <kvik@a-b.xyz> wrote:
>
> Check /sys/log/mail for a fingerprint.
>
> ------------------------------------------
> 9fans: 9fans
> Permalink: https://9fans.topicbox.com/groups/9fans/Te20476748ab5e4ba-M519efe14ca0b3cb7c3836dee
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Gmail vs upas

[kvik]

> unfortunately it doesn't look like anything is being logged

Turns out I misremembered where upas/fs logs the failure:

; upas/fs -f /imaps/imap.gmail.com/$gmail
upas/fs: opening /imaps/imap.gmail.com/$gmail: imap.gmail.com/imaps:cert for imap.gmail.com not recognized: sha256=3oXL6BEgeiAKLNpIZtBn0GdxDoMdiDRpuS8qX2xm8oM

> imap.gmail.com/imaps:tlsClient: tls: local invalid x509/rsa
certificate

Perhaps retry with a clean /sys/lib/tls/mail.

Re: [9fans] Gmail vs upas

[David du Colombier]

If the server uses a X.509 certificate with a SHA256 signature,
you need SHA2 signature support in libsec.

http://9legacy.org/9legacy/patch/libsec-x509-sha2.diff
http://9legacy.org/9legacy/patch/libsec-x509-sig.diff

-- 
David du Colombier

Re: [9fans] Gmail vs upas

[Steven Stallion]

Looks like that was it - thanks a lot David! IMAP is syncing as we
speak. It looks like I have my work cut out for me to get things
updated to 9legacy's latest and greatest.

Cheers,
Steve

On Thu, Nov 28, 2019 at 1:00 PM David du Colombier <0intro@gmail.com> wrote:
>
> If the server uses a X.509 certificate with a SHA256 signature,
> you need SHA2 signature support in libsec.
>
> http://9legacy.org/9legacy/patch/libsec-x509-sha2.diff
> http://9legacy.org/9legacy/patch/libsec-x509-sig.diff
>
> --
> David du Colombier
>
> ------------------------------------------
> 9fans: 9fans
> Permalink: https://9fans.topicbox.com/groups/9fans/Te20476748ab5e4ba-Meaf5abb51d5c93fe38204912
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Gmail vs upas

[ori]

> Looks like that was it - thanks a lot David! IMAP is syncing as we
> speak. It looks like I have my work cut out for me to get things
> updated to 9legacy's latest and greatest.
> 
> Cheers,
> Steve

I've put some patches together that made acme Mail a bunch more usable
for me.  Mostly around showing read/replied flags.  If you want, feel
free to prepare patches for 9legacy, and I'll be more than happy to
give a hand:

	https://code.9front.org/hg/plan9front/rev/c6d4c49b1653
	https://code.9front.org/hg/plan9front/rev/aca41046f6ee

There are also a couple of upas changes, but our upas in 9front is
based on nupas, and not the one in 9legacy -- still, I was staring at
the imap code in both to understand what was going on, and I think the
approach to not fetching everything should be applicable:

	https://code.9front.org/hg/plan9front/rev/99a26b67689a

Unrelatedly, would there be interest in adding the `$split{cmd} syntax
from 9atom to 9legacy?  I think it's currently the only reason that
git9 doesn't work out of the box there, and it's very nice syntax.

Re: [9fans] Gmail vs upas

[Richard Miller]

On the tangential subject of acme mail, I have a very infrequent bug
where the header of a newly arrived message pops up in the position
where the /mail/fs/mbox window used to be, some time after the mbox
window has been adjusted by another window opening.  Does anyone else
see this?  Is there a known patch on some fork which fixes it?

Re: [9fans] Gmail vs upas

[Anthony Martin]

ori@eigenstate.org once said:
> Unrelatedly, would there be interest in adding the `$split{cmd} syntax
> from 9atom to 9legacy?  I think it's currently the only reason that
> git9 doesn't work out of the box there, and it's very nice syntax.

I'm not a fan of the `word{...} syntax. It's odd to
allow a word in the middle of a syntactic form like
that. I can't think of any other part of rc(1) that
does that. Is there any?

I used to use a pair of functions named pushifs and
popifs to easily control backquote tokenization but
over time I realized that I only used them when I
wanted no tokenization at all, with $ifs set to ''
or '\n'.

So I ported the "{...} mechanism from mash(1) to my
local copy of rc(1) and haven't looked back since.

Cheers,
  Anthony

Re: [9fans] Gmail vs upas

[ori]

> On the tangential subject of acme mail, I have a very infrequent bug
> where the header of a newly arrived message pops up in the position
> where the /mail/fs/mbox window used to be, some time after the mbox
> window has been adjusted by another window opening.  Does anyone else
> see this?  Is there a known patch on some fork which fixes it?

I haven't seen this particular redraw artifact, but I've seen other
smaller ones. Is there anything in particular that you can do to
reproduce it?

I just took a quick poke through the 9front and plan9port changes, and
I see a couple of things that should probably be cherry-picked[1], but
not anything related to artifacts.

(Also, looks like git9's git/log's filtering by path is busted.
TODO added.)

[1] some obvious bugfixes on plan9port, which should apply to 9legacy.
	- 7ca1c90109e17dced4b38fbaadea9d2cf39871b7 (fix memory leak)
	- 219cf22d6863a21a7378fc5481bb05bbb6edd2dc (large file fixes)
	- edfe3c016fe6ef10c55f7a17aab668214ec21efc (sam issue, free str instead of free)
	- 76b9347a5fa3a0970527c6ee1b97ef1c714f636b (avoid div-by-0)
	- a82a8b6368274d77d42f526e379b74e79c137e26 (apply +/- only once)
	- dfac95269ab7944810043fb9e78557b06ed3a767 (update tag after control event)
	- fff818fe878ca5edfbac85b15e77ada2acb8ea0f (avoid inverted textselect range)

Let me know if there are others I missed.

Re: [9fans] Gmail vs upas

[Richard Miller]

> I haven't seen this particular redraw artifact, but I've seen other
> smaller ones. Is there anything in particular that you can do to
> reproduce it?

It turns out that there is:

1 acme -f $font /acme/mail/guide; guide opens at top of right column
2 left-click on Mail; mbox list opens in right column under /acme/mail/guide
3 right-click on a message number; message opens in right column under mbox
4 right-click on message's 'expand' box; message fills right column, overwriting mbox list
5 send myself email from another rio window
6 new message header appears in the middle of the opened message, where the mbox list used to be