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

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?

Potential segfault in localtime_r invocations

| Details | | | ------------------- | ---------------------------------------------- | | Package | chrono | | Version | 0.4.19 | | URL | https://github.com/chronotope/chrono/issues/499 | | Date | 2020-11-10 |

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.

Potential segfault in the time crate

| Details | | | ------------------- | ---------------------------------------------- | | Package | time | | Version | 0.1.44 | | URL | https://github.com/time-rs/time/issues/293 | | Date | 2020-11-18 | | Patched versions | >=0.2.23 | | Unaffected versions | =0.2.0,=0.2.1,=0.2.2,=0.2.3,=0.2.4,=0.2.5,=0.2.6 |

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.

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.

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

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

Caused by:
  failed to get a 200 OK response, got 500
  headers:
  	HTTP/1.1 100 Continue

  	HTTP/1.1 500 Internal Server Error
  	content-type: application/json
  	content-length: 20
  	date: Mon, 11 Oct 2021 18:34:28 GMT

  body:
  {"error":"NotFound"}

Oct 11 19:34:28.618 ERROR chartered_web::middleware::logging: 127.0.0.1:51358 - "PUT /a/[snip]/o/dave/api/v1/crates/new" 500 2.248239ms "cargo 1.56.0-nightly (b51439fd8 2021-08-09)" "Err(Database(Query(NotFound)))"

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

• [x] CREATE_CRATE should imply PUBLISH_VERSION, etc.
• [x] We also need "public" orgs which imply VISIBLE for everyone.
• [x] 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?
• [x] ~should public crates in otherwise private orgs be a thing?~ No
• [x] ~Does MANAGE_USERS imply the user can set a crate/group to public?~ Can now only pick when creating the org

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

dotenv is Unmaintained

| Details | | | ------------------- | ---------------------------------------------- | | Status | unmaintained | | Package | dotenv | | Version | 0.15.0 | | URL | https://github.com/dotenv-rs/dotenv/issues/74 | | Date | 2021-12-24 |

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.

ansi_term is Unmaintained

| Details | | | ------------------- | ---------------------------------------------- | | Status | unmaintained | | Package | ansi_term | | Version | 0.12.1 | | URL | https://github.com/ogham/rust-ansi-term/issues/72 | | Date | 2021-08-18 |

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.

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.

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.

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