Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion auth.go
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ type Auth interface {
func (conn *Conn) Auth(methods []Auth) error {
if methods == nil {
uid := strconv.Itoa(os.Geteuid())
methods = []Auth{AuthExternal(uid), AuthCookieSha1(uid, getHomeDir())}
methods = getDefaultAuthMethods(uid)
}
in := bufio.NewReader(conn.transport)
err := conn.transport.SendNullByte()
Expand Down
8 changes: 8 additions & 0 deletions auth_default_other.go
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
//go:build !windows
// +build !windows

package dbus

func getDefaultAuthMethods(user string) []Auth {
return []Auth{AuthExternal(user)}
}
5 changes: 5 additions & 0 deletions auth_default_windows.go
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
package dbus

func getDefaultAuthMethods(user string) []Auth {
return []Auth{AuthCookieSha1(user, getHomeDir())}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with changing the default behavior to not use this mechanism on non-Windows platforms, but why make the AuthCookieSha1 definition completely Windows-only? Users can still explicitly specific authentication mechanisms, so this change would remove the possibility to use this mechanism (and strictly speaking, be a breaking change since this removes an exported type). Even though EXTERNAL is pretty much always used when it works (i.e. on Unix), maybe some users have cases where even on Unix, EXTERNAL can't be used but SHA1 can.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because all usage of SHA1 must be deprecated. I am also trying to build applications that embed go-dbus without ability to use SHA1 anymore.

I do not believe any Linux distribution has working and configured SHA1 Auth that is secure. Nor can it be used securely.

Is there any pre-existing evidence of any SHA1 usage on Linux? I posit, if there was, it would have been upgraded to sha256 by now.

If such pre-existing deployments exist I can add an opt-in build tag for this. However it is insecure, and dbus spec needs upgrades to sha256.

Cc @martinpitt any advice here? Or who else to ask?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand. Generally I try to stick to what the official spec says, and there it is still mentioned as the "recommended authentication mechanism for platforms and configurations where EXTERNAL cannot be used."

However it is insecure, and dbus spec needs upgrades to sha256.

I advise you to then open an issue with the spec itself: https://gitlab.freedesktop.org/dbus/dbus/-/issues

I can't judge how much / whether this is actually used - my gut feeling is that this is pretty rare, but I have been surprised before. We can merge this and see if any bug reports come in; but as long as the spec still mentions this mechanism, I'm prepared to revert this PR if this actually causes issues for users.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

File renamed without changes.
Loading