Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split proxy/client serials based on lower bit #57

Merged
merged 3 commits into from
May 7, 2024

Conversation

sophie-h
Copy link
Contributor

@sophie-h sophie-h commented Apr 7, 2024

Separation between messages created by client and proxy was ensured by
requiring the client to use monotonically increasing serials and adding
an offset to distinguish the client message from proxy messages.

The requirement to only send messages with increasing serials cannot be
ensured by libraries godbus or zbus.

This commit instead reserves the lower_bit=0 space for client messages
and the lower_bit=1 for messages created by the proxy. This gets rid of
any serial translation mechanism and the requirement for increasing serials.
However, it limits the possible values of serials available to the client
to about half of the usual maximum value.

Closes #46

@sophie-h sophie-h force-pushed the wip/sophie-h/even-odd-serials branch 2 times, most recently from aa36e27 to 5816eaf Compare April 12, 2024 12:29
@sophie-h
Copy link
Contributor Author

What changes with this is that clients can re-use serials. I can't guarantee that this doesn't has potential security implications since I'm not familiar enough with the codebase.

@sophie-h sophie-h force-pushed the wip/sophie-h/even-odd-serials branch from 5816eaf to b76beeb Compare April 12, 2024 12:43
@sophie-h sophie-h marked this pull request as ready for review April 12, 2024 12:44
@sophie-h sophie-h force-pushed the wip/sophie-h/even-odd-serials branch from b76beeb to 23581ea Compare April 12, 2024 12:54
@sophie-h sophie-h changed the title Use even serials for proxy and add for client Split proxy/client serials based on lower bit Apr 12, 2024
flatpak-proxy.c Outdated Show resolved Hide resolved
@sophie-h sophie-h force-pushed the wip/sophie-h/even-odd-serials branch from 23581ea to d36e8b0 Compare April 12, 2024 14:46
flatpak-proxy.c Outdated Show resolved Hide resolved
flatpak-proxy.c Outdated Show resolved Hide resolved
@matthiasclasen
Copy link
Contributor

Thanks for writing a patch!

@sophie-h sophie-h force-pushed the wip/sophie-h/even-odd-serials branch 2 times, most recently from 225133d to 184b2ce Compare April 15, 2024 10:29
flatpak-proxy.c Outdated Show resolved Hide resolved
flatpak-proxy.c Show resolved Hide resolved
@sophie-h sophie-h force-pushed the wip/sophie-h/even-odd-serials branch from 184b2ce to 779235e Compare April 15, 2024 15:56
flatpak-proxy.c Outdated Show resolved Hide resolved
@swick
Copy link
Contributor

swick commented Apr 16, 2024

LGTM but we should definitely get another review in.

@sophie-h sophie-h force-pushed the wip/sophie-h/even-odd-serials branch from 779235e to 935eeda Compare April 16, 2024 13:23
Separation between messages created by client and proxy was ensured by
requiring the client to use monotonically increasing serials and adding
an offset to distinguish the client message from proxy messages.

The requirement to only send messages with increasing serials cannot be
ensured by libraries godbus or zbus.

This commit instead reserves the high-bit=0 space for client messages
and the high-bit=1 for messages created by the proxy. This gets rid of
any serial translation mechanism and the requirement for increasing serials.
However, it limits the possible values of serials available to the client
to about half of the usual maximum value.

Closes flatpak#46
@sophie-h sophie-h force-pushed the wip/sophie-h/even-odd-serials branch from 935eeda to 4f081c7 Compare April 27, 2024 21:08
@sophie-h
Copy link
Contributor Author

Rebased due to merge conflict.

@alexlarsson
Copy link
Member

Some minor comments from me, but otherwise this looks good to me.

@alexlarsson
Copy link
Member

Well, one more comment: Maybe MAX_CLIENT_SERIAL can be made much much larger. We're only emitting "fake" requests at the beginning of the session when setting up the view of bus names, so thre is never going to be 2^31 of them.

I think MAX_CLIIENT_SERIAL should be set to something like G_MAXUINT32 - 65536, which would allow more end-user serial numbers.

sophie-h added 2 commits May 7, 2024 12:45
Don't split via lower bit of the serial but instead use a much higher
number for MAX_CLIENT_SERIAL since there are very few fake requests we
need to do.
@sophie-h
Copy link
Contributor Author

sophie-h commented May 7, 2024

I have changed the code to

#define MAX_CLIENT_SERIAL (G_MAXUINT32 - 65536)

@alexlarsson
Copy link
Member

lgtm

@alexlarsson alexlarsson merged commit 1bcfaea into flatpak:main May 7, 2024
3 of 4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Revisit requirement on monotone increasing client serials
5 participants