profile
viewpoint

SamWhited/poetrytex 8

This repo has moved to https://git.sr.ht/~samwhited/poetrytex

SamWhited/checkin 3

This repo has been moved to https://git.sr.ht/~samwhited/checkin

SamWhited/contracard 3

This repo has been moved to https://git.sr.ht/~samwhited/contracard

SamWhited/Conversations 3

Conversations is an open source XMPP (formally known as Jabber) client for Android 4.0+ smart phones.

ags799/bootlaces 1

Andrew Sharp's boot configurations for Clojure code.

dmcgowan/docker 0

Docker - the open-source application container engine

SamWhited/AfterTheQuake 0

This repo has been moved to https://git.sr.ht/~samwhited/afterthequake

SamWhited/AT2014 0

This repo has been moved to https://git.sr.ht/~samwhited/at2014

SamWhited/blackfriday 0

Blackfriday: a markdown processor for Go

SamWhited/buildkit 0

concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit

issue commentgolang/go

proposal: spec: generic programming facilities

Personally I don't know how I feel about the entire Go community changing over from multiple returns to Result

I don't think this would happen. Like @azunymous said, lots of functions have multiple return types and an erro but a result couldn't contain all those other returned values at the same time. Parametric polymorphism isn't the only feature needed to do something like this; you'd also need tuples and destructuring. Then you could create a generic result that can contain multiple values or an error.

adg

comment created time in 2 days

fork SamWhited/unofficial-apis

A collection of unofficial apis. Designed to inspire your next Friday night hack

fork in 5 days

PR opened xsf/xeps

Xep0389

Overhauls the structure of the document to make it easier to follow. This revision also adds more information to the success element to support flows where the server sets the final JID.

+225 -103

0 comment

1 changed file

pr created time in 6 days

create barnchSamWhited/xeps

branch : xep0389

created branch time in 6 days

PR opened xsf/xeps

XEP-0393: editorial changes from LC feedback

Simple clarifications and terminology fixes based on LC feedback for XEP-0393.

+21 -7

0 comment

1 changed file

pr created time in 6 days

push eventSamWhited/xeps

Sam Whited

commit sha 73b323a4c62a369c774d8c1a6c82a1ee0f2d223d

XEP-0393: editorial changes from LC feedback

view details

push time in 6 days

create barnchSamWhited/xeps

branch : xep0393_lc_feedback

created branch time in 6 days

issue commentgolang/go

proposal: change standard library to check for io.EOF using errors.Is

TL;DR — I have a general rule of thumb that I don't return io.EOF and always return a new error if I need more context, or, more frequently, handle the io.EOF at the read call site because EOF isn't actually an error. We should not encourage checking that wrapped errors started out in life as an EOF, we should treat them like any other error.


I tend to think of io.EOF as a special case; a sentinel value indicating expected behavior, not an error. This already leads to the unfortunate "if err != nil && err != io.EOF" scattered throughout my codebase anywhere some code calls Read. It also frequently leads to bugs in my code where I either forget to check for and handle the EOF from a Read call, or I some piece of code returns EOF when I'm not expecting it and I can't always easily track down where such a generic error message is coming from. This all happens because EOF is not an error, it's expected behavior. The error comes later when I go to do something with my data and realize that the expected data wasn't completely read, or was the wrong data, etc.

Because of this, I don't think I've ever seen a place where checking for io.EOF further up the stack (not directly at the call site) would do anything but hide a bug where I wanted to handle io.EOF before, and I don't think this should be encouraged. There are occasions where we want to actually return an io.EOF (eg. if the function in question also has read like semantics), so we need a way to distinguish between an actual new error and an EOF while still keeping context around. EOF doesn't provide any context, and one read site that returned EOF is as good as another, so I generally don't think it should be wrapped with more context if we want to continue to treat it as a magical sentinel value.

This means that if I really want to check for io.EOF further up the stack, I should just return it and not wrap it so that it can be treated as a signal, not an error. If I do want to signal to a user of my code that the EOF was unexpected and therefore an actual error, I should return an error, not EOF (which does not indicate that an error occurred). If I'm a user of a library that has wrapped EOF, this to me indicates that this was an actual error and I should treat the wrapped error just like I would any other error (and it doesn't matter that the root error was an EOF signal).

tonistiigi

comment created time in 6 days

issue commentmellium/xmpp

xmpp, sasl: ensure PRECIS profiles are applied to all SASL inputs

A few notes from a chat on the channel:

  • SCRAM requires SASLprep (we'll use UsernameCaseMapped instead, making us technically compliant but it's not likely to ever matter. If it becomes a problem we can likely come up with a way to enact a policy to to deny passwords that would work with one but not the other).
  • PLAIN requires that you don't do any prep and let the server handle it. I am unsure if this matters or not yet, in theory mechanisms should be stable after applying them several times and if they're not it's a bug in PRECIS. Will having the client and server both apply the enforce step of UsernameCaseMapped ever break anything? I don't think so. Or will it matter at all? Maybe it's just a waste of cycles for clients to do it.
SamWhited

comment created time in 7 days

issue openedmellium/xmpp

xmpp, sasl: ensure PRECIS profiles are applied to all SASL inputs

Currently the UsernameCaseMapped [RFC 8265] profile of PRECIS [RFC 8264] is applied to the localpart of JIDs when they are parsed with the mellium.im/xmpp/jid package. However, PRECIS is not applied to the authorization identity or password if set. These should likely use the UsernameCaseMapped and OpaqueString profiles.

This issue is to determine how and where to apply these profiles (if at all). Eg. should this happen in xmpp.SASL or in sasl.Negotiator, somewhere else, or left up to the user as it is now?

created time in 7 days

issue commentcheckpoint-restore/go-criu

Tag SemVer-compatible tags to facilitate go modules

Currently I really hate modules wink It feels complicated and I have no idea what I am doing.

I'd urge you to take your concerns to the go-nuts mailing list or the issue tracker if you're running into actual problems with how modules interacts with this project. So far whenever I've brought up concerns, including issues with real projects, I've been told that these are a small percentage of users and modules solves 90% of use cases, etc. I do not believe this is the case, but unless they get more complaints the Go team are likely to continue asserting that everything is fine.

That being said, the only problem I see is that this module declares itself as /v4 (which is correct) but then imports github.com/checkpoint-restore/go-criu, so it will actually be importing an older version of itself.

The go.mod file appears to be out of date as well, and the go.sum file doesn't seem to exist (but this should be committed).

thaJeztah

comment created time in 11 days

issue commentmellium/xmpp

docs: validate relative links in CI

This can use mellium.im/checkcmd.

SamWhited

comment created time in 11 days

issue openedhorazont/aiosasl

PyPi still shows unsupported SASL mechanisms

Unspecified SASL mechanisms were removed in #6, but are still listed on https://pypi.org/project/aiosasl/.

created time in 11 days

issue openedmellium/xmpp

sasl: redesign SASL module

The SASL module doesn't have a very good API. Credentials are on the state machine, meaning every time a new mechanism with new credential types gets added a new option/method has to be added to the state machine and mechanisms can be used with the wrong type of credentials attached.

This issue is a placeholder for a real proposal for a new API, and a place to solicit feedback on a redesign of mellium.im/sasl.

created time in 13 days

issue openedmellium/xmpp

sasl: add support for SASL ANONYMOUS

Add support for the ANONYMOUS SASL mechanism as defined by RFC 4505.

created time in 13 days

delete branch SamWhited/xeps

delete branch : password_storage_fix_ref

delete time in 13 days

issue openedmellium/xmpp

xmpp: design API for handling virtual hosts

Currently the various functions that create and negotiate a session take an origin and location JID up front. However, it is common for servers to decide the origin JID based on the to address of the initial stream and a list of virtual hosts that they are configured to serve.

Create a new API that lets servers get access to the initial stream header or related data before negotiating the session so that they can decide and set the origin JID based on whether or not they support the correct host.

created time in 13 days

issue openedmellium/xmpp

xmpp: implement server side of SASL

The server side of SASL is currently unimplemented in the SASL stream feature and needs to be implemented. This may require coming up with a proposal for a new API for the feature.

https://github.com/mellium/xmpp/blob/master/sasl.go#L75-L77

created time in 14 days

pull request commentortuman/jackal

Store salted and hashed passwords in the database

Ping; is this waiting on anything? Thanks!

SamWhited

comment created time in 15 days

issue commentmellium/xmpp

`xmpp: features advertised out of order` when not negotiating SASL/Dialback over S2S

Reopening this because it doesn't appear to be related to the other problem I mentioned since I don't think @horazont's config is doing SASL EXTERNAL or anything. I'll need a stream features config (that does not use custom stream features, just the built in ones) and an XML trace (with sensitive bits removed, of course) from either @horazont or @wrflemin before I can diagnose this.

horazont

comment created time in 16 days

IssuesEvent

issue openedmellium/xmpp

Consider how/if dialback should be supported

XEP-0220: Server Dialback is a DNS-based identity verification protocol for server-to-server (S2S) connections. I am unsure whether we want to add this as one of the core features in the xmpp package, in its own package, in its own repo, or maybe not implement it at all. I consider it a legacy technology that shouldn't be used, but it's possible that it is still widely used.

To decide this it may be helpful to answer the following questions:

  • How widespread is dialback use on the public Jabber network today?
  • Are there any services that are considered "important" that only support dialback (and what do we mean by "important")?
  • The Go standard library does not support DNSSEC and support is currently unplanned (see golang/go#13279, https://golang.org/issues/13279), does this affect its use or should we consider only implementing it if DNSSEC can be verified?

created time in 16 days

issue commentxsf/xeps

XEP-0438: Best practices for password hashing and storage

You know that I have done a lot of job about SCRAM-SHA-256(-PLUS) that it is implemented in several softwares (XMPP servers/clients/libraries and not XMPP related too).

Yes, I am aware. However, appeals to authority do not make you correct.

In RFC 8600 that I promote since a long time, it is clear:

As I said, I think that RFC is wrong. There are no known pre-image attacks against SHA-1 which makes it just fine in an HMAC. Therefore it is roughly equivalent security. If we both agree that channel binding is better than no channel binding, that means that we should prioritize the two channel binding versions over the non-channel binding versions. That is my logic for the current order. If you want me to change it you're going to need to justify your ordering with something other than "an RFC says so" and "I have done work in this area".

Like I have noted, no problem for Obsolete part : DIGEST-MD5 > CRAM-MD5

I'm sorry, I guess I misunderstood. It looks like you're using a greater than sign to say that DIGEST-MD5 is better to implement than CRAM-MD5, but this is not what I said in the document. I said "DIGEST-MD5 = CRAM-MD5". However, if I'm misunderstanding and there's no problem that's fine then :)

Neustradamus

comment created time in 17 days

issue commentxsf/xeps

XEP-0438: Best practices for password hashing and storage

I am not sure but SCRAM-SHA-256(-PLUS) is prefered than SCRAM-SHA-1(-PLUS) no?

No, they are equivalent. It is time that we started thinking about moving off of SCRAM-SHA-1 just in case, but it's not actually any weaker than 256 as far as we know. The PLUS variants are preferred over the non-plus variants, but otherwise the SHA-1 is just used in an HMAC so it's still fine. It's better to have a version with channel binding (ie. SCRAM-SHA-1-PLUS) over a version with no channel binding but a slightly less weak hash in the HMAC (SCRAM-SHA-256).

Warning the RFC 8600 is not listed in this XEP:

I think this is unrelated to the XEP and outside of its scope, but I admit that I haven't read it all the way through so I'll go back and double check that I haven't missed anything. I disagree with its assessment in the section you quoted, but I'll re-read to make sure I'm not misunderstanding or missing some important context. Thanks for the link.

No problem for Obsolete part, the order is good "DIGEST-MD5 > CRAM-MD5".

At one point DIGEST-MD5 might have been superior to CRAM-MD5 but they're both just broken now.

Neustradamus

comment created time in 17 days

issue commentmellium/xmpp

`xmpp: features advertised out of order` when not negotiating SASL/Dialback over S2S

Superseded by #58

In the mean time we could make this error better or document that this is not supported, but I suspect that the implementation is straightforward enough that I've gone ahead and included it in the milestone for the next version. If it turns out that it can't be done in time I'll document or tweak the error.

horazont

comment created time in 17 days

issue openedmellium/xmpp

xmpp: support mutual TLS authentication for S2S connections

Server to server connections use mutual TLS authentication, either via direct TLS or STARTTLS. Currently we do not support this feature and therefore server to server connections are impossible because the auth bit will never be set on the connection state.

Look into adding support for TLS auth on server to server connections and implement it if it's trivial, or write a proposal if it requires API changes.

Supersedes issue #32

created time in 17 days

issue closedmellium/xmpp

`xmpp: features advertised out of order` when not negotiating SASL/Dialback over S2S

In prometheus-xmpp-blackbox-exporter, when I was still not negotiating SASL/Dialback (e.g. in this revision: https://github.com/horazont/prometheus-xmpp-blackbox-exporter/commit/4e0577e74d3c604c45af3c0a3bd7f5fc58d364e0), I got the xmpp: features advertised out of order with some servers. movim.eu triggered it, as did conversations.im (which is an ejabberd), while my own (sotecware.net, Prosody 0.11) did not.

closed time in 17 days

horazont

issue commentmellium/xmpp

`xmpp: features advertised out of order` when not negotiating SASL/Dialback over S2S

I just realized that this is likely just the StartTLS stream feature not marking the session as authenticated. Right now the StartTLS feature doesn't actually support acting as auth for server to server connections. I will open a new issue to deal with this.

horazont

comment created time in 17 days

push eventmellium/xmpp

Sam Whited

commit sha 8942e93cb85cafd42708b1a5b662486baadd2387

.builds: default to SourceHut repo for CI See #51 Signed-off-by: Sam Whited <sam@samwhited.com>

view details

Sam Whited

commit sha eb68b47263e629ef7501717fe700b75b14f7f40e

.builds: sync to GitHub on push Signed-off-by: Sam Whited <sam@samwhited.com>

view details

Sam Whited

commit sha 05d10a71c6e91688b6f2951056b4ad5ba61b193c

docs: update contributing doc for SourceHut Signed-off-by: Sam Whited <sam@samwhited.com>

view details

Sam Whited

commit sha e84534f70a03b6e3e4f4c27d124eac4f9f2e89a3

xmpp: remove duplicate stream feature data cache Data returned for caching from stream feature negotiation is always stored on the session so that it can be accessed later. Previously it was also being stored on the current stream features list cache, but this is redundant since we always have access to the session. Signed-off-by: Sam Whited <sam@samwhited.com>

view details

Sam Whited

commit sha 4161b93aefba4c6725994a4d1c5eb9524d7295bc

xmpp: check every feature in the list for required Previously if a required feature in a list of stream features could not be negotiated (eg. because one of its necessary state bits wasn't set) it would be skipped over and the stream features list would not be marked as containing required features. This means that if no feature in the list was marked as required, we would assume that was the end of stream negotiation and bail out early. Instead, make sure to always parse every feature and check if it's required, even if it can't be negotiated. This way we know that we need to try again and negotiate one of the required features after negotiating the optional features. Fixes #47 Signed-off-by: Sam Whited <sam@samwhited.com>

view details

Sam Whited

commit sha ac109a462986fc4132850b4792388942ff17e550

xmpp: proxy ConnectionState through wrapped conns When we wrap a connection during stream negotiation (eg. to add compression, or some other transformation), proxy through the ConnectionState method. This way the TLS connection state isn't hidden from the session which will need it to pass to SASL mechanisms that use it. See #45 Signed-off-by: Sam Whited <sam@samwhited.com>

view details

Sam Whited

commit sha 785e7d9ce94209c51ddd890b2fe6582dfe116ab4

xmpp: proxy ConnectionState through teeConn When we use the TeeIn/TeeOut functionality our connections get wrapped in a teeConn which would hide the connection state if the underlying connection is a *tls.Conn (or anything else that exposes TLS connection state). Proxying it through lets us access the connection state from all the way up at the Session level (which means that SASL mechanisms can get access to it). See #45 Signed-off-by: Sam Whited <sam@samwhited.com>

view details

Sam Whited

commit sha ac511d7bb64b4db3b9039824d013d360fe77aaa4

xmpp: provide access to tls.ConnectionState When a session's underlying net.Conn gets wrapped, the underlying tls.ConnectionState becomes inaccessible. Saving the connState and adding a method on Session to access it will let us proxy it forward to things that need it (eg. SASL) so that they don't break if we negotiate stream features that wrap the conn. See #45 Signed-off-by: Sam Whited <sam@samwhited.com>

view details

Sam Whited

commit sha 3ca280202eb041adb381e0177c480615ebd2c97d

xmpp, sasl2: use Session ConnectionState for SASL Previously we attempted to pull the tls.ConnectionState out of the Session's underlying net.Conn, however, even if the underlying connection is a *tls.Conn if it is wrapped at all the connection state would become unavailable. Instead, use the new ConnectionState method on Session which will always proxy down into the top most *tls.Conn. Fixes #45 Signed-off-by: Sam Whited <sam@samwhited.com>

view details

Sam Whited

commit sha 0e217cd1ebe1902b1853370d00822f282ae3064e

xmpp: make STARTTLS always required TLS (or at the time, SSL) may have been an optional feature in the past, but it's not anymore. These days it's far more likely that a server will always want to require TLS in some form, so giving the user the ability to turn it off just means we're giving users who won't understand the consequences of their actions a knob to twiddle. In the very rare case that a user actually *does* need STARTTLS to be an optional stream feature, I don't think it's something we should support. For this rare use case, they'll have to take the maintenance burden on themselves by copy/pasting the StartTLS feature code and tweaking it for their needs. Fixes #50 Signed-off-by: Sam Whited <sam@samwhited.com>

view details

Sam Whited

commit sha adee40ac2ff5792e14e7af8c9f06efd6f9fd137f

internal/integration: new integration test helpers The internal/integration package is designed to make it easy to spin up and configure servers for integration tests. It is not meant to be used directly, instead it is meant to aid in writing other packages that spin up specific servers and tools. Fixes #42 Signed-off-by: Sam Whited <sam@samwhited.com>

view details

Sam Whited

commit sha 5f31d172661105a582ad38e0eb2eaa9a0bdea917

internal/integration/prosody: new package The prosody package lets you configure and spin up an instance of the Prosody XMPP server (https://prosody.im/) for use in integration tests. Signed-off-by: Sam Whited <sam@samwhited.com>

view details

Sam Whited

commit sha 47285a3762cf3e18c5bbe4c3dad93c5108a5f3f2

internal/integration/ejabberd: new package The ejabberd package lets you configure and spin up an instance of the Ejabberd XMPP server (https://www.ejabberd.im/) for use in integration tests. Signed-off-by: Sam Whited <sam@samwhited.com>

view details

Sam Whited

commit sha 30d2dffe5227b9b2162ad688677afbad07396efa

.builds: run integration tests Signed-off-by: Sam Whited <sam@samwhited.com>

view details

Sam Whited

commit sha 2910e1ec3afde89c3a02a3f53e49ac8573c75de4

design: update proposal 42 Update the integration testing proposal to mention that the new API is not covered by the compatibility promise since it's in the internal/ tree. Signed-off-by: Sam Whited <sam@samwhited.com>

view details

push time in 18 days

issue commentmellium/xmpp

xmpp: if STARTTLS is advertised, make it always required

Proposed patch: https://lists.sr.ht/~samwhited/mellium-devel/patches/10529

SamWhited

comment created time in 18 days

issue openedmellium/xmpp

Make SASL feature accept auth restarts

RFC 6120 §6.4.2 says:

If the initiating entity subsequently sends another <auth/> element and the ongoing authentication handshake has not yet completed, the receiving entity MUST discard the ongoing handshake and MUST process a new handshake for the subsequently requested SASL mechanism.

However we don't appear to be doing this. I am not aware of anywhere this is used, and I doubt most implementations support this, but it's worth being compliant just in case.

created time in 18 days

issue closedmellium/xmpp

TeeIn/TeeOut sometimes sees encrypted data

In prometheus-xmpp-blackbox-exporter, I sometimes set TeeIn/TeeOut to os.Stderr for debugging. With some servers, I then see encrypted data on stderr after TLS negotiation.

One server where I got encrypted data is my own (sotecware.net, Prosody 0.11), one where I got plaintext is movim.eu.

closed time in 19 days

horazont

issue commentmellium/xmpp

TeeIn/TeeOut sometimes sees encrypted data

Nevermind, reproduced with the echobot. Unsure how this is different form the little quick example I made, but for some reason it is. It does appear to be fixed on master.

horazont

comment created time in 19 days

issue commentmellium/xmpp

TeeIn/TeeOut sometimes sees encrypted data

@horazont can you check if this one happens on the latest commit as well? I was able to reproduce this for a while, but now that I go back and try again with the released version (not master) I can't reproduce it and can't remember what I did to make it happen.

horazont

comment created time in 19 days

PR closed mellium/xmpp

Add experimental integration test packages

This adds three packages, internal/integration, internal/integration/prosody, and internal/integration/ejabberd that can be used to spin up servers with a specific configuration and easily run tests against them. It is likely not yet ready for merge, but I wanted to push up what work I had done to remind me to get back to it one of these weekends and because someone was asking about a related testing issue.

Fixes #42

+712 -4

1 comment

8 changed files

SamWhited

pr closed time in 19 days

pull request commentmellium/xmpp

Add experimental integration test packages

Closing this since development is being moved to SourceHut (GitHub PRs will still be accepted, however). When I get back to it, I'll post this as a patch set to the mellium-devel mailing list.

SamWhited

comment created time in 19 days

PR closed mellium/xmpp

ibb: add new package

Implement XEP-0047: In-Band Bytestreams.

Fixes #19

+481 -0

1 comment

3 changed files

SamWhited

pr closed time in 19 days

pull request commentmellium/xmpp

ibb: add new package

Closing this since development is being moved to SourceHut. When I get back to it, I'll send the patch to the new mellium-devel mailing list.

SamWhited

comment created time in 19 days

PR closed horazont/xmpp-blackbox-exporter

Use encoding API for sending register IQs

I wasn't sure if you'd actually want this since your way already works and is likely more efficient, but since you mentioned it I thought I'd make this PR to point out that stanzas can be created with the struct based API from the stanza package, which may or may not be easier depending on your situation. I have not tested this PR since it was mostly just meant as an example.


While looking at the code mentioned in mellium/xmpp#33 I noticed that this project was using the "Send" method to send Register IQs instead of "SendIQ". Because Send doesn't block and wait for the IQ response, what we really need to remove the need for a TokenReader is to use the Encode method which already exists. Updating to use Encode makes it easier to send stanzas without having to write a large TokenReader implementation, at the cost of efficiency (see mellium/xmpp#38).

+9 -36

1 comment

1 changed file

SamWhited

pr closed time in 19 days

issue commentmellium/xmpp

Use of TeeIn/TeeOut breaks SCRAM-*-PLUS

See #55

horazont

comment created time in 19 days

Pull request review commentmellium/xmpp

xmpp: check every feature in the list for required

 parsefeatures: 			s.features[tok.Name.Space] = nil  			feature, ok := getFeature(tok.Name, features)--			if ok && s.state&feature.Necessary == feature.Necessary && s.state&feature.Prohibited == 0 {+			if ok { 				req, data, err := feature.Parse(ctx, s.in.d, &tok) 				if err != nil { 					return nil, err 				}+				sf.req = sf.req || req

This line was the core of the problem. If we see that a feature in the list was required we mark that it exists so that we know we're not done with negotiation. Previously, this happened after the checks to see if we're allowed to negotiate the feature right this moment on the next line. We don't care about that though, even if we can't negotiate the feature right this moment we might be able to negotiate it in the next step after negotiating some more optional features (like StartTLS in this case).

SamWhited

comment created time in 19 days

issue commentmellium/xmpp

Fails to negotiate SASL if starttls is not required and SASL is offered before TLS

@horazont could you try out #56 and confirm that it fixes the issue you were seeing?

horazont

comment created time in 19 days

PR opened mellium/xmpp

xmpp: check every feature in the list for required

Previously if a required feature in a list of stream features could not be negotiated (eg. because one of its necessary state bits wasn't set) it would be skipped over and the stream features list would not be marked as containing required features. This means that if no feature in the list was marked as required, we would assume that was the end of stream negotiation and bail out early. Instead, make sure to always parse every feature and check if it's required, even if it can't be negotiated. This way we know that we need to try again and negotiate one of the required features after negotiating the optional features.

Fixes #47

Signed-off-by: Sam Whited sam@samwhited.com

+23 -20

0 comment

1 changed file

pr created time in 19 days

PR opened mellium/xmpp

Fix SCRAM-*-PLUS with TeeIn/TeeOut

This needs a test before it can be merged.

Fixes #45

+72 -9

0 comment

6 changed files

pr created time in 19 days

issue commentgolang/go

proposal: spec: generic programming facilities

On Wed, May 6, 2020, at 13:00, Ian Lance Taylor wrote:

People understand that int64(v) is a type conversion and F(v) is a function call, even though they look exactly the same.

I don't have an opinion one way or the other right now on the proposal syntax, but I don't think this particular example is very good. It may be true for built in types, but I have actually gotten confused by this exact problem several times myself (I was grepping for a function definition and being very confused about how the code was working before I realized it was likely a type and I couldn't find the function because it wasn't a function call at all). Not the end of the world, and probably not a problem at all for people who like fancy IDEs, but I've wasted 5 minutes or so grepping around for this multiple times.

—Sam

-- Sam Whited

adg

comment created time in 19 days

issue commentmellium/xmpp

`xmpp: features advertised out of order` when not negotiating SASL/Dialback over S2S

Can either of you provide the exact configuration you used to create this problem (preferably as a small, minimal working example that I can run) and the XML of a session between you and the server (removing the password and any other sensitive bits, of course)? Hopefully I'll be able to get back to some of the outstanding issues this weekend, having a MWE and an XML trace will make debugging this go much faster.

horazont

comment created time in 20 days

issue commentmellium/xmpp

Migrate project to SourceHut

Blocked on https://todo.sr.ht/~sircmpwn/todo.sr.ht/214

SamWhited

comment created time in 20 days

issue commentmellium/xmpp

Migrate project to SourceHut

Turns out SourceHut doesn't allow you to delete issues, even if they're spam, accidentally contain personal information, were filed in error, etc. I am not sure if this is a blocker or not for using their issue tracker. On the one hand, I can always edit issues to remove the body if it's a problem or contact support if there's spam (though this is unlikely on such a smalls ervice), but I'd feel much more comfortable if I had control over this projects data. I will consider this before finishing the migration.

SamWhited

comment created time in 21 days

issue closedmellium/xmpp

People having trouble accessing mellium.im/sasl

I've had multiple reports this morning that people have had trouble accessing mellium.im/sasl this morning. I cannot reproduce this issue myself, so I assume this is one of a couple of things:

  • Netlify was briefly down (this happens frequently)
  • GitHub was briefly down (this happens a lot too, and I had trouble with it yesterday for a while, but I'm still getting reports so this seems unlikely)
  • Netlify gave me a shared IP that peoples corporate firewalls are mistakingly blocking (this has also happened in the past)
  • I enabled IPv6 on the website and people have misconfigured happy eyeballs support that is causing Go to think they can use the AAAA records, but then when it tries to hit the IPs the network stack fails

/cc @Barben360

closed time in 22 days

SamWhited

issue commentmellium/xmpp

People having trouble accessing mellium.im/sasl

Right after posting this I found the problem. I forgot that Git doesn't push tags by default, so when recreating this repo and then pushing back to GitHub from Sourcehut the tags all got removed. I'm repushing tags for all libraries from my repo now, and SASL is already complete and should be back to normal.

SamWhited

comment created time in 22 days

issue openedmellium/xmpp

People having trouble accessing mellium.im/sasl

I've had multiple reports this morning that people have had trouble accessing mellium.im/sasl this morning. I cannot reproduce this issue myself, so I assume this is one of a couple of things:

  • Netlify was briefly down (this happens frequently)
  • GitHub was briefly down (this happens a lot too, and I had trouble with it yesterday for a while, but I'm still getting reports so this seems unlikely)
  • Netlify gave me a shared IP that peoples corporate firewalls are mistakingly blocking (this has also happened in the past)
  • I enabled IPv6 on the website and people have misconfigured happy eyeballs support that is causing Go to think they can use the AAAA records, but then when it tries to hit the IPs the network stack fails

created time in 22 days

issue commentmellium/xmpp

Migrate project to SourceHut

@Barben360 it also just occured to me that GitHub was down for a bit yesterday (it seems to go down quite a lot as well). Sadly, the Go package system is built on a lot of very fragile infrastructure and the Go team says it's not a problem. The only other thing I can think of is that I added an IPv6 address to mellium.im a day or two ago. Is it possible that you have some sort of misconfiguration in your network stack that's causing IPv6 or happy eyeballs to break?

SamWhited

comment created time in 22 days

issue commentmellium/xmpp

Migrate project to SourceHut

No, the reason I use a vanity import is that I can move the hosting provider without breaking peoples packages. This is working for me, so my guess is that Netlify was down (sadly, they're what the Go team recommends but my metrics show that they're down constantly). Can you try again? If you still can't get to it, it may be that the shared IPs that Netlify uses have been blacklisted by your corporate firewall. Alternative hosting provider suggestions would be welcomed, Netlify has not been a good experience but I don't make any money on this project and they're free. /cc @Barben360

SamWhited

comment created time in 22 days

push eventmellium/xmlstream

Sam Whited

commit sha 0e4f9fd4d2be8ebba18c09c32d3a4c81b8a152f2

.builds: sync to GitHub Signed-off-by: Sam Whited <sam@samwhited.com>

view details

push time in 22 days

push eventmellium/blogsync

Sam Whited

commit sha 5083f77d6a5a04a6c2e8f065c87351f48870505b

.builds: verify DCO Signed-off-by: Sam Whited <sam@samwhited.com>

view details

push time in 22 days

push eventmellium/sasl

Sam Whited

commit sha 81ced1c7c3256cd662ddd0b650aa302828f31eca

.builds: sync to GitHub Signed-off-by: Sam Whited <sam@samwhited.com>

view details

push time in 22 days

delete branch mellium/mellium.im

delete branch : move_workflows

delete time in 22 days

PR closed mellium/mellium.im

.github: move workflows to fix PR closer

Signed-off-by: Sam Whited sam@samwhited.com

+1 -1

0 comment

1 changed file

SamWhited

pr closed time in 22 days

PR opened mellium/mellium.im

.github: move workflows to fix PR closer

Signed-off-by: Sam Whited sam@samwhited.com

+1 -1

0 comment

1 changed file

pr created time in 22 days

create barnchmellium/mellium.im

branch : move_workflows

created branch time in 22 days

delete branch mellium/mellium.im

delete branch : move_workflows

delete time in 22 days

PR closed mellium/mellium.im

.github: move workflows to fix PR closer

Signed-off-by: Sam Whited sam@samwhited.com

+1 -1

0 comment

1 changed file

SamWhited

pr closed time in 22 days

PR opened mellium/mellium.im

.github: move workflows to fix PR closer

Signed-off-by: Sam Whited sam@samwhited.com

+1 -1

0 comment

1 changed file

pr created time in 22 days

create barnchmellium/mellium.im

branch : move_workflows

created branch time in 22 days

delete branch mellium/mellium.im

delete branch : move_workflows

delete time in 22 days

PR closed mellium/mellium.im

.github: move workflows to fix PR closer

Signed-off-by: Sam Whited sam@samwhited.com

+1 -1

0 comment

1 changed file

SamWhited

pr closed time in 22 days

push eventmellium/mellium.im

Sam Whited

commit sha 928c55ff6b5db1b4efa3bc7ddf4de49b3d49884c

.github: move workflows to fix PR closer Signed-off-by: Sam Whited <sam@samwhited.com>

view details

push time in 22 days

PR opened mellium/mellium.im

.github: move workflows to fix PR closer

Signed-off-by: Sam Whited sam@samwhited.com

+0 -0

0 comment

1 changed file

pr created time in 22 days

create barnchmellium/mellium.im

branch : move_workflows

created branch time in 22 days

delete branch mellium/mellium.im

delete branch : sync_to_github

delete time in 22 days

PR closed mellium/mellium.im

Sync to GitHub

This PR is just a test to see if it's closed by the recent action that was added. The unrelated sync build job will be merged shortly.

+117 -0

0 comment

10 changed files

SamWhited

pr closed time in 22 days

delete branch mellium/mellium.im

delete branch : pr_closer

delete time in 22 days

PR closed mellium/mellium.im

PR Closer

This is a test to see if auto closing PRs works.

+104 -0

0 comment

9 changed files

SamWhited

pr closed time in 22 days

PR opened mellium/mellium.im

Sync to GitHub

This PR is just a test to see if it's closed by the recent action that was added. The unrelated sync build job will be merged shortly.

+117 -0

0 comment

10 changed files

pr created time in 22 days

create barnchmellium/mellium.im

branch : sync_to_github

created branch time in 22 days

PR opened mellium/mellium.im

PR Closer

This is a test to see if auto closing PRs works.

+104 -0

0 comment

9 changed files

pr created time in 22 days

create barnchmellium/mellium.im

branch : pr_closer

created branch time in 22 days

delete branch mellium/xmpp

delete branch : sync_to_github

delete time in 22 days

delete branch mellium/xmpp

delete branch : default_repo_ci_to_sourcehut

delete time in 22 days

PR merged mellium/xmpp

.builds: default to SourceHut repo for CI

See #51

Signed-off-by: Sam Whited sam@samwhited.com

+2 -2

0 comment

2 changed files

SamWhited

pr closed time in 22 days

PR merged mellium/xmpp

Sync to GitHub

Sync the repo to GitHub any time we push to SourceHut.

+15 -2

0 comment

3 changed files

SamWhited

pr closed time in 22 days

push eventmellium/xmpp

Sam Whited

commit sha 8942e93cb85cafd42708b1a5b662486baadd2387

.builds: default to SourceHut repo for CI See #51 Signed-off-by: Sam Whited <sam@samwhited.com>

view details

Sam Whited

commit sha eb68b47263e629ef7501717fe700b75b14f7f40e

.builds: sync to GitHub on push Signed-off-by: Sam Whited <sam@samwhited.com>

view details

push time in 22 days

PR opened mellium/xmpp

Sync to GitHub

Sync the repo to GitHub any time we push to SourceHut.

+15 -2

0 comment

3 changed files

pr created time in 22 days

create barnchmellium/xmpp

branch : sync_to_github

created branch time in 22 days

PR opened mellium/xmpp

.builds: default to SourceHut repo for CI

See #51

Signed-off-by: Sam Whited sam@samwhited.com

+2 -2

0 comment

2 changed files

pr created time in 22 days

create barnchmellium/xmpp

branch : default_repo_ci_to_sourcehut

created branch time in 22 days

issue commentmellium/xmpp

Fails to negotiate SASL if starttls is not required and SASL is offered before TLS

Okay, I understand what's happening now. The problem is that auth is being ignored (because it requires TLS first), but that means that it's never being put in the list of features that we saw, so we think there are no more required features and the session is over. We need some way to signal that there was a required feature in the list, but that it couldn't be negotiated yet and that we should try again to see if its prerequisites are now satisfied.

horazont

comment created time in 22 days

Pull request review commentiNPUTmice/Conversations

Typo you you

     <string name="no_storage_permission">Grant Conversations access to external storage</string>     <string name="no_camera_permission">Grant Conversations access to the camera</string>     <string name="sync_with_contacts">Synchronize with contacts</string>-    <string name="sync_with_contacts_long">Conversations wants permission to access your contacts to match your contact list with your contacts to show their full names and avatars.\n\nIt will only read your contacts and match them locally without uploading them to your server.</string>+    <string name="sync_with_contacts_long">Conversations wants permission to access your contacts to match your XMPP contact list with your contacts and show their full names and avatars.\n\nIt will only read your contacts and match them locally without uploading them to your server.</string>

Maybe "roster" instead of "XMPP contact list"? Or if we think roster isn't great terminology, is there something else that doesn't include "XMPP" (which most users probably shouldn't have to know about)?

"to show their full names and avatars" sounded better to me, it's not that it wants access and to show the full name, it wants access because it can't show the full name without it.

licaon-kter

comment created time in 22 days

Pull request review commentiNPUTmice/Conversations

Typo you you

     <string name="clear_other_devices">Clear devices</string>     <string name="clear_other_devices_desc">Are you sure you want to clear all other devices from the OMEMO announcement? The next time your devices connect, they will reannounce themselves, but might not receive messages sent meanwhile.</string>     <string name="error_no_keys_to_trust_server_error">There are no usable keys available for this contact.\nCould not fetch new keys from the server. Maybe there is something wrong with your contact’s server?</string>-    <string name="error_no_keys_to_trust_presence">There are no usable keys available for this contact.\nMake sure you both of you have presence subscription on.</string>+    <string name="error_no_keys_to_trust_presence">There are no usable keys available for this contact.\nMake sure both of you have presence subscription on.</string>

"Make sure you both have presence subscription" sounds better to me, but I couldn't tell you why. In addition, "have presence subscription on" sounds odd to me, but I know that's not part of this PR, it just may be worth thinking about later.

licaon-kter

comment created time in 22 days

issue commentmellium/xmpp

Fails to negotiate SASL if starttls is not required and SASL is offered before TLS

The problem appears to be that if there are no more required features we assume that we're done with negotiation, however this is not the case if STARTTLS is not required. I'm not sure what the logic here was supposed to do, but I'll go reread RFC 6120 at some point soon and figure out what the end of stream initiation is actually supposed to look like. We can probably fix this easily enough by only terminating stream negotiation when a feature marks the connection as Ready, but I need to review all this code to make sure. Sorry for the long delays today, I am only partially at my desk.

horazont

comment created time in 22 days

issue openedmellium/xmpp

Migrate project to SourceHut

Now that their project hub is live, I am planning on migrating this project to SourceHut.

The following steps need to be completed:

  1. [x] Create project with repos to match everything in the Mellium Org on GitHub
  2. [x] Remove all existing GitHub Commit build jobs from dispatch.sr.ht
  3. [ ] Ensure each project as a GitHub PR build job on dispatch.sr.ht
  4. [ ] Ensure each project has a sync build job in the .builds/ tree
  5. [ ] Finish the issue tracker migration tool and run it, then close down the GitHub tracker

created time in 22 days

issue commentwriteas/writeas-gtk

Build broken because code.as is down

Not to worry; thank you, and as always, let me know if there's anything I can do to help!

SamWhited

comment created time in 22 days

push eventmellium/communique-tui

Sam Whited

commit sha ea1a8d5d18b951c0a460696b33ddf59a629c9557

.builds: fix broken DCO check Signed-off-by: Sam Whited <sam@samwhited.com>

view details

push time in 22 days

push eventmellium/communique-tui

Sam Whited

commit sha 5b16e664d83e5a44a536cc569976cea9b3b925e1

.builds: move to SourceHut Signed-off-by: Sam Whited <sam@samwhited.com>

view details

push time in 22 days

push eventmellium/verbmux

Sam Whited

commit sha d08ecfdd6ee9c5e70905e7358effd1d811dfb649

all: fix doc badge in readme Signed-off-by: Sam Whited <sam@samwhited.com>

view details

push time in 22 days

push eventmellium/sysexit

Sam Whited

commit sha 4d1e4c75622543a668c31814361d58f1fec39e33

.builds: move to SourceHut Signed-off-by: Sam Whited <sam@samwhited.com>

view details

push time in 22 days

push eventmellium/sysexit

Sam Whited

commit sha 3c9cd65b01c8877fe545251cfa77ac3acfe05b90

sysexit: fix docs badge in readme Signed-off-by: Sam Whited <sam@samwhited.com>

view details

push time in 22 days

issue commentmellium/xmpp

Fails to negotiate SASL if starttls is not required and SASL is offered before TLS

@horazont can you get me the XML from a negotiation attempt with another client that has an XML console? I just noticed that in your print statement it appears to offer StartTLS twice even after TLS is already negotiated. I'm not sure if this could cause an issue, but if I can see the XML it may make what's happening more obvious (I'm getting confused trying to look through the printed info).

horazont

comment created time in 23 days

push eventmellium/sasl

Sam Whited

commit sha 80ccf70d68606d987dcc0f119fa30f7a5e48eee1

docs: sync FUNDING.yml with mellium.im/xmpp Signed-off-by: Sam Whited <sam@samwhited.com>

view details

push time in 23 days

delete branch mellium/sasl

delete branch : invalid_tls_unique_error

delete time in 23 days

more