Skip to content

Split proxy/client serials based on lower bit#57

Merged
alexlarsson merged 3 commits into
flatpak:mainfrom
sophie-h:wip/sophie-h/even-odd-serials
May 7, 2024
Merged

Split proxy/client serials based on lower bit#57
alexlarsson merged 3 commits into
flatpak:mainfrom
sophie-h:wip/sophie-h/even-odd-serials

Conversation

@sophie-h

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

Copy link
Copy Markdown
Contributor

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

Comment thread flatpak-proxy.c
@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
Copy Markdown
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
Comment thread flatpak-proxy.c Outdated
@sophie-h sophie-h force-pushed the wip/sophie-h/even-odd-serials branch from 23581ea to d36e8b0 Compare April 12, 2024 14:46
Comment thread flatpak-proxy.c Outdated
Comment thread flatpak-proxy.c Outdated
@matthiasclasen

Copy link
Copy Markdown
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
Comment thread flatpak-proxy.c Outdated
Comment thread flatpak-proxy.c
@sophie-h sophie-h force-pushed the wip/sophie-h/even-odd-serials branch from 184b2ce to 779235e Compare April 15, 2024 15:56
Comment thread flatpak-proxy.c
@swick

swick commented Apr 16, 2024

Copy link
Copy Markdown
Contributor

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
Copy Markdown
Contributor Author

Rebased due to merge conflict.

Comment thread flatpak-proxy.c
Comment thread flatpak-proxy.c
@alexlarsson

Copy link
Copy Markdown
Member

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

@alexlarsson

Copy link
Copy Markdown
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

sophie-h commented May 7, 2024

Copy link
Copy Markdown
Contributor Author

I have changed the code to

#define MAX_CLIENT_SERIAL (G_MAXUINT32 - 65536)

@alexlarsson

Copy link
Copy Markdown
Member

lgtm

@alexlarsson alexlarsson merged commit 1bcfaea into flatpak:main May 7, 2024
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