protonmail / gluon Goto Github PK

As of #406 (comment) it is now possible to build gluon on a musl-based system (Alpine Linux 3.20), hence I believe an update to the semver is in order to facilitate a new proton-bridge version to be compiled and packaged on musl-based systems.

The file limits/imap.go uses MaxUint32 which is too big for the int type on 32 bits and causes builds on those architectures to fail. This seems to be a known issue based on proton-bridge's BUILDS.md file, but I don't see any effort made to solve it. Is this specific number required, or can something else 32-bit-friendly be used?

Dear @ProtonMail team,

For more security, can you add supports of:

• SCRAM-SHA-1
• SCRAM-SHA-256
• SCRAM-SHA-512
• SCRAM-SHA3-512

Same with TLS Channel Binding:

• SCRAM-SHA-1-PLUS
• SCRAM-SHA-256-PLUS
• SCRAM-SHA-512-PLUS
• SCRAM-SHA3-512-PLUS

Details:

"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".

• SCRAM-SHA-1(-PLUS):
  -- https://tools.ietf.org/html/rfc5802
  -- https://tools.ietf.org/html/rfc6120

• SCRAM-SHA-256(-PLUS):
  -- https://tools.ietf.org/html/rfc7677 since 2015-11-02
  -- https://tools.ietf.org/html/rfc8600 since 2019-06-21: https://mailarchive.ietf.org/arch/msg/ietf-announce/suJMmeMhuAOmGn_PJYgX5Vm8lNA

• SCRAM-SHA-512(-PLUS):
  -- https://tools.ietf.org/html/draft-melnikov-scram-sha-512

• SCRAM-SHA3-512(-PLUS):
  -- https://tools.ietf.org/html/draft-melnikov-scram-sha3-512

https://xmpp.org/extensions/inbox/hash-recommendations.html

-PLUS variants:

• RFC5056: On the Use of Channel Bindings to Secure Channels: https://tools.ietf.org/html/rfc5056
• RFC5929: Channel Bindings for TLS: https://tools.ietf.org/html/rfc5929
• Channel-Binding Types: https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml
• RFC 9266: Channel Bindings for TLS 1.3: https://tools.ietf.org/html/rfc9266

IMAP:

• RFC9051: Internet Message Access Protocol (IMAP) - Version 4rev2: https://tools.ietf.org/html/rfc9051

LDAP:

• RFC5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted: Challenge Response Authentication Mechanism (SCRAM) Secrets: https://tools.ietf.org/html/rfc5803

HTTP:

• RFC7804: Salted Challenge Response HTTP Authentication Mechanism: https://tools.ietf.org/html/rfc7804

2FA:

• Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication: https://datatracker.ietf.org/doc/html/draft-ietf-kitten-scram-2fa

IANA:

• Simple Authentication and Security Layer (SASL) Mechanisms: https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml

Linked to:

• scram-sasl/info#1

I have been running in to issues with importing old emails into proton mail via the proton mail bridge due to the RFC5322 validation. TBH, I think this validation should probably be removed completely - if emails can be received that are missing the date field and have matching from and sender fields, then it should be possible to import such a message via imap.

The check for value in From and Sender header at

seems too strict as the specification doesn't mention that the values in the fields cannot be the same. Furthermore, it is common for email messages to have different names in the fields but with the same email addresses such as:

From: "John Doe via Service" <[email protected]>
Sender: "Service" <[email protected]>

The check should either be removed or perhaps modified so it takes into consideration the equality of the names too.

gluon depends on ProtonMail/go-mbox, which is a fork of emersion/go-mbox with some minor changes. It would be beneficial if you open a PR and/or contact the upstream author to get the changes merged upstream.

Hi ! And first of all, thank you for your work 🚀

I'm using gluon server with a client that only follows IMAP4rev1 RFC, and I got an error while parsing a gluon IMAP response, as it does not follow the ABNF syntaxe everywhere

Here is the steps to reproduce :

>> telnet 127.0.0.1 1143
a0 login [email protected] pass
...
a5 UID SEARCH ALL
* SEARCH 6 7
a5 OK command completed in 337.51µs

As you can see, the server took "337.51µs" to respond... "µs" -> here is the problem, "µ" is not an ASCII char.
As defined in rfc3501 (IMAP4rev1 that Gluon tends to follow), IMAP syntaxe should follow ABNF.
Quote from rfc3501:

resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
resp-text = ["[" resp-text-code "]" SP] text
text = 1*TEXT-CHAR
TEXT-CHAR = any CHAR except CR and LF

and the ABNF rfc5234 tells that CHAR are only US-ASCII

CHAR = %x01-7F
; any 7-bit US-ASCII character,
; excluding NUL

"µ" char is not in this range (as it is UTF-8)

The problem is located here :

I think this should be fixed to follow rfc3501

Thank you !!

Are the ANTLR grammars for this available somewhere?
They don't seem to be in this repo.

Currently, only inLogger and outLogger settings are supported.The output of error logs only supports std.The log format also does not support customization, such as attaching dates, timestamps, and specific code line numbers

gluon was recently packaged in Debian and also synced to the Ubuntu archive.

We noticed that tests were unreliable.

Here are 2 examples of the package building, resulting in 2 different sets of tests failing:

• https://launchpadlibrarian.net/705045335/buildlog_ubuntu-noble-amd64.golang-github-protonmail-gluon_0.17.0-2_BUILDING.txt.gz
• https://launchpadlibrarian.net/709744464/buildlog_ubuntu-noble-amd64.golang-github-protonmail-gluon_0.17.0-2_BUILDING.txt.gz

The third time the build was successful. This is not critical since we now have a package but will surely be problematic during following upgrades.

I tried to reproduce locally, especially with the -race flag. This flag is not present in our build but since I suspect a race condition between several tests I thought it could make it easier to trigger. But no luck so far. I noticed you run the tests in CI with this flag so maybe you have already encountered the problem?

In the first build attempt:

• For TestDeleteSelectedMailboxWithRemoteUpdateCausesDisconnect it looks like the IMAP server did not have time to process the mailbox creation before the test tried to select it.
• For TestDraftScenario it also looks like the IMAP server was one step behind the test.

In the second build attempt:

• TestRemoteDeletionPool was stuck and was killed by the timeout. I also notice you raised this timeout to 15min in your CI but when this is test is running fine, it runs in 0.03s, so raising the timeout should not really solve this issue.

MailBoxes are created using utils.NewRandomMailboxID() in the tests, so several independent tests should not impact each other.

I also checked the connection management (looking at runOneToOneTest() and withConnections()) and did not see any obvious bug like sharing a connection between tests, reusing a connection, forgetting to check connection closing errors, etc.

Maybe the IMAP server is not always reliably answering to requests in the same order?

Let me know if you need more details or have other ideas to try and reproduce to pinpoint the issue.

Hello everyone,

Thanks for developing this new IMAP library and improving the bridge!

I have noticed that you generate ANTLR C++ parser to process the IMAP commands and this results in a need to pull some static libraries and do some heavy lifting to communicate between go and C++. I currently run the bridge on a bunch of architectures that you don't normally support. It's normally pretty easy with pure go, but quite a pain if you need to interface with C++.

ANTLR seems to be capable of generating go directly without having to go through C++: https://github.com/antlr/antlr4/blob/master/doc/go-target.md. Please consider using that instead. It should significantly simplify your integration and testing process too.

I use the bridge with my Proton email account. Unfortunately, the bridge doesn't support RFC 5256, which makes it extremely difficult to make use of all the features of my client. I also experience a large usability issue in that when viewing emails in my client, they are sorted by UID instead of date, which causes me to view messages out of order.

I originally opened an issue in the bridge repository, but then noticed that it uses gluon for the imap server.

Prior art would be https://github.com/emersion/go-imap-sortthread.

Hello.

Please excuse me for my beginner level question, but first time building any go app/project.

I downloaded the source of this, but when used go build I got the following errors:

marcell@raspberry:/tmp/gluon-source$ go build
go: downloading github.com/mattn/go-sqlite3 v1.14.13
go: downloading github.com/sirupsen/logrus v1.8.1
go: downloading golang.org/x/exp v0.0.0-20220827204233-334a2380cb91
go: downloading github.com/emersion/go-imap v1.2.1-0.20220429085312-746087b7a317
go: downloading google.golang.org/protobuf v1.27.1
go: downloading golang.org/x/sys v0.0.0-20220722155257-8c9f86f7a55f
go: downloading golang.org/x/sync v0.0.0-20220722155255-886fb9371eb4
go: downloading ariga.io/atlas v0.5.1-0.20220717122844-8593d7eb1a8e
go: downloading github.com/hashicorp/hcl/v2 v2.10.0
go: downloading github.com/zclconf/go-cty v1.8.0
go: downloading github.com/google/go-cmp v0.5.8
go: downloading github.com/agext/levenshtein v1.2.1
go: downloading github.com/mitchellh/go-wordwrap v0.0.0-20150314170334-ad45545899c7
# github.com/ProtonMail/gluon/internal/parser
/usr/bin/ld: cannot find -lparser: No such file or directory
/usr/bin/ld: cannot find -lparser_gen: No such file or directory
/usr/bin/ld: cannot find -lproto: No such file or directory
/usr/bin/ld: cannot find -lprotobuf: No such file or directory
/usr/bin/ld: cannot find -lantlr4-runtime: No such file or directory
collect2: error: ld returned 1 exit status

Is there any building process documented?

By the way, I am running Arm64.

Gnome Evolution isn't working with the updated ProtonBridge. Debug logging shows this series of commands

[imapx:B] I/O: LOGIN...
[imapx:B] I/O: 'B00055 OK [CAPABILITY IDLE IMAP4rev1 MOVE STARTTLS UIDPLUS UNSELECT] Logged in'
[imapx:B] I/O: 'B00056 LIST "" INBOX'
[imapx:B] I/O: 'B00056 OK LIST'
[imapx:B] I/O: 'B00057 LSUB "" INBOX'
[imapx:B] I/O: 'B00057 OK LSUB'
[imapx:B] I/O: 'B00058 LIST "" INBOX'
[imapx:B] I/O: 'B00058 OK LIST'
[imapx:B] I/O: 'B00059 LSUB "" INBOX'
[imapx:B] I/O: 'B00059 OK LSUB'

The symptom inside Evolution is no visible folders. This is new for the Gluon version of ProtonBridge. Emulating this through IMAP literals by way of openssl s_client -connect localhost:1143 -starttls imap -crlf I can reproduce this.

A007 LSUB "" INBOX
A007 OK LSUB

Indicating no folders. Experimenting with other parameters I can get a folder list through:

A0005 LSUB "" "*"
* LSUB (\Unmarked) "/" "Folders/bulk"
* LSUB (\Archive \Noinferiors \Unmarked) "/" "Archive"
* LSUB (\Marked) "/" "Folders/notices"
* LSUB (\Marked) "/" "Folders/drips"
* LSUB (\Marked) "/" "Folders/susefactory"
* LSUB (\Junk \Noinferiors \Unmarked) "/" "Spam"
* LSUB (\Drafts \Noinferiors \Unmarked) "/" "Drafts"
* LSUB (\Flagged \Noinferiors \Unmarked) "/" "Starred"
* LSUB (\Marked \Noinferiors \Trash) "/" "Trash"
* LSUB (\Noselect \Unmarked) "/" "Folders"
* LSUB (\Marked \Noinferiors \Sent) "/" "Sent"
* LSUB (\Noselect \Unmarked) "/" "Labels"
A0005 LSUB OK

This looks like Gluon is not respecting RFCs.

A0001 OK [CAPABILITY IDLE IMAP4rev1 MOVE STARTTLS UIDPLUS UNSELECT] Logged in

IMAP4rev1 is defined in RFC3501. Section 5.1 includes this definition

The case-insensitive mailbox name INBOX is a special name reserved to
mean "the primary mailbox for this user on this server". The
interpretation of all other names is implementation-dependent.

1. Can you add in your documentation the results of ImapTest for gluon? In the same format as:

https://imapwiki.org/ImapTest/ServerStatus

2. Perhaps you can also work with the Dovecot/ImapTest folks to incorporate your results into their web page.

For further decoupling from big tech backed infrastructure/langs, it could be both powerful and interesting to port to V (https://github.com/vlang/v) since it's so close to Go syntactically and such an effort could help contribute toward the ongoing push towards 1.0 of the language. It could certainly make the library more performant.