search

jborean93 / pykrb5

Python krb5 API interface
MIT License
17 stars 8 forks source link

Creds serialization and deserialization #45

Closed zarganum closed 4 months ago

zarganum commented 4 months ago

Creds (de)serialization to/from the FILE ccache format (vesion 4) and KCM ccache protocol.

Use case: loading/storing of Creds objects in implementation-external cache memory, with TTL aligned to ticket validity.

MIT only: krb5_marshal_credentials krb5_unmarshal_credentials

Example usage:

bytes = krb5.marshal_credentials(ctx, creds)
uncreds = krb5.unmarshal_credentials(ctx, bytes)
zarganum commented 4 months ago
  1. forgot to add one last line to test_creds_serialization(): assert creds.ticket == uncreds.ticket
  2. for some reason gcc still warns on implicit declarations of krb5_marshal_credentials and krb5_unmarshal_credentials in mit tests... but each CI run costs 55 minutes, omg...
jborean93 commented 4 months ago

The bulk of the time in CI is compiling all the macOS wheels. In the past there was no arm macOS image to use so compiling was quite time consuming. I believe GHA now has arm images we can use so there's probably some work that can be done to improve those times. Still I'm not seeing 55 minutes, the summary from the latest run is 10 minutes 22 seconds. Are you saying that adding that assertion line causes CI to run for that time? If so you might have to investigate what that is doing and why it might be taking so long locally.

zarganum commented 4 months ago

Jordan, I appreciate your responsiveness and apologize for not being clear enough. The last assertion I wanted to add confirms the ticket itself is properly deserialized and is just a binary block compare; it is expected to be submicro- or even nanoseconds. This assertion is not a concern... the concern is a computational costs that Github bills you.

The CI duration is indeed shown as 10m 22s (astronomical time between start and end?). But the usage is 55m 0s (~23m for MacOS wheels, ~26m for Ubuntu tests, plus ~5m for MacOS tests).

Aren't these 55 minutes representing the total computational cost billed by Github? I am holding the "last line" mini-commit because don't want to ruin your budget. Let me know if you are fine with that:)

Many thanks

zarganum commented 4 months ago

you'd probably want to cut away the unsupported Python 3.7 right now, and plan for 3.8 EOL after October 2024. https://devguide.python.org/versions/

jborean93 commented 4 months ago

Ah no worries, thanks for your concern and thinking about this. I haven’t hit the limits, or received notifications that I’m close to them, for the free open source tier so commit away. I believe public repos don’t even have limits but I’m not 100% confident on that. I probably should look at making the build process a bit more efficient but for now it is what it is.

zarganum commented 4 months ago

I added some more test assertions. It appears that Python (3.11 in my case) is interning byte sequences returned by krb5 calls, at least the deserialized ticket byte object appears the same as it was before serialization. However I assume the initial copies still remain in the runtime process memory and will get freed eventually in __dealloc__. They are just not used by Python anymore.