w4 / chartered Goto Github PK

Sometimes cargo check will hang seemingly randomly when pulling the git repo, even though git clone succeeds just fine. I think this is when the repo is missing expected files like config.json but that's yet to be confirmed.

Potential segfault in the time crate

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

The affected functions from time 0.2.7 through 0.2.22 are:

• time::UtcOffset::local_offset_at
• time::UtcOffset::try_local_offset_at
• time::UtcOffset::current_local_offset
• time::UtcOffset::try_current_local_offset
• time::OffsetDateTime::now_local
• time::OffsetDateTime::try_now_local

The affected functions in time 0.1 (all versions) are:

• at
• at_utc

Non-Unix targets (including Windows and wasm) are unaffected.

Patches

Pending a proper fix, the internal method that determines the local offset has been modified to always return None on the affected operating systems. This has the effect of returning an Err on the try_* methods and UTC on the non-try_* methods.

Users and library authors with time in their dependency tree should perform cargo update, which will pull in the updated, unaffected code.

Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3. series.

Workarounds

No workarounds are known.

References

time-rs/time#293

See advisory page for additional details.

crates are well hidden behind most other endpoints as we can just return a 404 but cargo publish becomes a bit of a problem. in the crates.io world you can publish any crate you want without 'pre-registering' it first and you just become the owner like that, but that's a bit problematic for us because there's some cases where we might wish to hide some crates from some users altogether.

currently in chartered cargo publish will only push to a registered crate that the user has the PUBLISH_VERSION permission for, returning a 403 if the user doesn't have the permission or a 404 if the user doesn't even have the VISIBLE permission. we should expose a 'create crate' endpoint for the web ui to use to register a crate and give the registering user 'owner' access to allow them to start pushing to it.

this means we don't have to rate limit pushes at all, but it does mean the create endpoint can leak private crate names (though only to authenticated users). this endpoint should be limited to 1 req/s to prevent help this from being feasible.

one thing to note is we do currently ignore the directory passed in the registry git definition:

[registries]
chartered = { git = "ssh://127.0.0.1:2233/this/is/ignored" }

perhaps we could, at some point in the future, have these 'subdirectories' scoped to certain teams or something? I think it's a little bit out of scope for an MVP release though

We have a dependents section on the crate page but it currently has placeholder text, so we need to implement reverse dependencies there. More importantly however, we need to make sure the user has the VISIBLE permission for each of these crates when pulling them

The tree we generate currently contains every single repository regardless of whether or not the user has the VISIBLE permission for it, we should filter this before sending it.. and maybe somehow cache the whole tree in memor so we don't have to grab it from the db and process it every time -- we can just take a 'scoped' version for the user instead

For OAuth users we collect some basic info on first login such as email, real name, some website links. We should allow password-based users to set these too and also for OAuth users to update them.

Should be easy just updating organisation_id on the crate but we need to make sure the user has CREATE_CRATE on both orgs. Proper UI needs to be in place to inform the user it's a destructive action. If we setup a redirect between old and new orgs the user needs to be informed some users may lose privileges.

mach is unmaintained

Last release was almost 4 years ago.

Maintainer(s) seem to be completely unreachable.

Possible Alternative(s)

These may or may not be suitable alternatives and have not been vetted in any way;

• mach2 - direct fork

See advisory page for additional details.

ansi_term is Unmaintained

The maintainer has adviced that this crate is deprecated and will not receive any maintenance.

The crate does not seem to have much dependencies and may or may not be ok to use as-is.

Last release seems to have been three years ago.

Possible Alternative(s)

The below list has not been vetted in any way and may or may not contain alternatives;

• anstyle
• console
• nu-ansi-term
• owo-colors
• yansi

Dependency Specific Migration(s)

• structopt, clap2

See advisory page for additional details.

Potential segfault in localtime_r invocations

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

Workarounds

No workarounds are known.

References

• time-rs/time#293

See advisory page for additional details.

OpenAPI seem to have a a nice little generator for both typescript (using fetch) and Rust (which we'll use without a runtime, just for the model generation). We should move over to this to reduce a lot of the code surrounding request/response types in both Typescript & Rust

We need a way to keep track of permissions, crates, etc. Ideally some sort of ORM with a query generator so we can have modifiable database backends without having to mess about with making sure our queries work for oracle when a megacorp scoops up my project and leaves me penniless

Steps to reproduce:

• Go to the login page (tested with /dashboard too)
• Press F5

We need a way to let the user login to the web ui to dish out permissions etc, do we go with OIDC? What about groups from GitLab or something? Do we make the groups in chartered? How will we manage SSH keys? So many questions, so little answers. Is there anybody out there?

I think we'll start with a Gitlab backend since that gives us user auth/groups/ssh keys out of the box

libsqlite3-sys via C SQLite CVE-2022-35737

It was sometimes possible for SQLite versions >= 1.0.12, < 3.39.2 to allow an array-bounds overflow when large string were input into SQLite's printf function.

As libsqlite3-sys bundles SQLite, it is susceptible to the vulnerability. libsqlite3-sys was updated to bundle the patched version of SQLite here.

See advisory page for additional details.

We should provide a way for crate owners to generate "deploy tokens" which are tokens that can be passed to cargo --token, that'll only have permission to publish to that crate

We also need a way to provide CI access to the private crates, maybe just personal access tokens? that'll take the place of the deploy token too since CI will just act as a normal user of chartered, just using a password (personal access token) for SSH auth.

This can be worked around for now by giving CI an SSH key and creating a normal account in chartered

All crates should be scoped to a group - group permissions will apply to crate permissions by default, however the crate permissions can be overridden. Group admins decide who gets to push new crates with the new permission NEW_CRATE.

Any attempts to push to an unscoped crate (ie. rand, instead of my-group/rand) will be disallowed.

This means per-group registries will have to be defined in ~/.cargo/config.toml:

[registries]
registry--cool   = { index = "ssh://chart.rs/cool" }
registry--uncool = { index = "ssh://chart.rs/uncool" }

This change should also allow for "global" permissions

This also needs the corresponding backend endpoints

Need to decide how we'll accept SSH keys:

• take a directory where we can write any files we want?
• take a path to a certificate and create it if it doesn't already exist?
• should we be creating certs already or should the admin do that while they're setting up chartered?

rusqlite/rusqlite#914

The two ways this can be approached are:

• a * 'user' which applies a set of permissions to any users not already listed, or:
• a checkbox to set public org y/n that implies VISIBLE for everyone

• CREATE_CRATE should imply PUBLISH_VERSION, etc.
• We also need "public" orgs which imply VISIBLE for everyone.
• Whether we keep around crate-level permissions and how they're factored in (other than doing a bitwise OR against group permissions) is still an open question - should someone in an org be able to be disallowed from viewing specific crates in that org?
• should public crates in otherwise private orgs be a thing? No
• Does MANAGE_USERS imply the user can set a crate/group to public? Can now only pick when creating the org

This could either happen:

• when the client requests, ie. a setTimeout just before the session is about to expire, or
• upon every request from the session

dotenv is Unmaintained

dotenv by description is meant to be used in development or testing only.

Using this in production may or may not be advisable.

Alternatives

The below may or may not be feasible alternative(s):

• dotenvy

See advisory page for additional details.

• /crates/new
• /crates/search
• /crates/:crate/owners
  • get
  • put
  • delete
• /crates/:crate/:version/yank
• /crates/:crate/:version/unyank
• /crates/:crate/:version/download

• Input needs validation, ie where the cargo registry spec defines strict values
• duplicate version for crate currently returns 'Failed to query database' (058e4ce)

Allow for clustering by allowing files to be uploaded to ie. an ftp server or S3, would be nice to have a Blob(/stream) or Redirect return type for the fetch method so we can just serve temporary credentials for the s3 object instead of streaming it through our http server

Right now we're just doing string comparisons on incoming messages, we should actually 'understand' these commands and acknowledge git client capabilities etc..

It'd be nice to cache the entire tree of chartered-git and filter it down based on the user rather than fetching every crate from the database and building the tree upon every git pull.