w4 / chartered Goto Github PK
View Code? Open in Web Editor NEW✈️ a private, authenticated, permissioned cargo registry
License: Do What The F*ck You Want To Public License
✈️ a private, authenticated, permissioned cargo registry
License: Do What The F*ck You Want To Public License
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)))"
mach is unmaintained
Details | |
---|---|
Status | unmaintained |
Package | mach |
Version | 0.3.2 |
URL | fitzgen/mach#63 |
Date | 2020-07-14 |
Last release was almost 4 years ago.
Maintainer(s) seem to be completely unreachable.
These may or may not be suitable alternatives and have not been vetted in any way;
See advisory page for additional details.
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 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
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
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
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.
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.
The two ways this can be approached are:
*
'user' which applies a set of permissions to any users not already listed, or:Potential segfault in
localtime_r
invocations
Details | |
---|---|
Package | chrono |
Version | 0.4.19 |
URL | chronotope/chrono#499 |
Date | 2020-11-10 |
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.
No workarounds are known.
See advisory page for additional details.
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
CREATE_CRATE
should imply PUBLISH_VERSION
, etc.VISIBLE
for everyone.public
crates in otherwise private orgs be a thing?MANAGE_USERS
imply the user can set a crate/group to public?Right now we're just doing string comparisons on incoming messages, we should actually 'understand' these commands and acknowledge git client capabilities etc..
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
dotenv is Unmaintained
Details | |
---|---|
Status | unmaintained |
Package | dotenv |
Version | 0.15.0 |
URL | dotenv-rs/dotenv#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.
The below may or may not be feasible alternative(s):
See advisory page for additional details.
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
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
Potential segfault in the time crate
Details | |
---|---|
Package | time |
Version | 0.1.44 |
URL | time-rs/time#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 |
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.
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.
No workarounds are known.
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
libsqlite3-sys
via C SQLite CVE-2022-35737
Details | |
---|---|
Package | libsqlite3-sys |
Version | 0.22.2 |
URL | https://nvd.nist.gov/vuln/detail/CVE-2022-35737 |
Date | 2022-08-03 |
Patched versions | >=0.25.1 |
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 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
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.
This also needs the corresponding backend endpoints
ansi_term is Unmaintained
Details | |
---|---|
Status | unmaintained |
Package | ansi_term |
Version | 0.12.1 |
URL | ogham/rust-ansi-term#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.
The below list has not been vetted in any way and may or may not contain alternatives;
See advisory page for additional details.
This could either happen:
Need to decide how we'll accept SSH keys:
Steps to reproduce:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.