mellowagain / gitarena Goto Github PK

This is totally possible if SMTP is enabled and configured but the question is how we would accomplish this when SMTP is disabled

net2 crate has been deprecated; use socket2 instead

The net2 crate has been deprecated
and users are encouraged to considered socket2 instead.

See advisory page for additional details.

While compiling gitarena locally, the dependency lettre complains about these imports being incorrect.

I am building this on on WSL 2.0 running Debian 10.

error[E0432]: unresolved imports `lettre::Mailbox`, `lettre::Tokio02Connector`, `lettre::Tokio02Transport`
  --> src/mail.rs:18:34
   |
18 | use lettre::{AsyncSmtpTransport, Mailbox, Message, Tokio02Connector, Tokio02Transport};
   |                                  ^^^^^^^           ^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^ no `Tokio02Transport` in the root
   |                                  |                 |
   |                                  |                 no `Tokio02Connector` in the root
   |                                  |                 help: a similar name exists in the module: `Tokio02Executor`
   |                                  no `Mailbox` in the root```

Data race when sending and receiving after closing a oneshot channel

If a tokio::sync::oneshot channel is closed (via the
oneshot::Receiver::close method), a data race may occur if the
oneshot::Sender::send method is called while the corresponding
oneshot::Receiver is awaited or calling try_recv.

When these methods are called concurrently on a closed channel, the two halves
of the channel can concurrently access a shared memory location, resulting in a
data race. This has been observed to cause memory corruption.

Note that the race only occurs when both halves of the channel are used
after the Receiver half has called close. Code where close is not used, or where the
Receiver is not awaited and try_recv is not called after calling close,
is not affected.

See tokio#4225 for more details.

See advisory page for additional details.

Integer overflow in hyper's parsing of the Transfer-Encoding header leads to data loss

When decoding chunk sizes that are too large, hyper's code would encounter an integer overflow. Depending on the situation,
this could lead to data loss from an incorrect total size, or in rarer cases, a request smuggling attack.

To be vulnerable, you must be using hyper for any HTTP/1 purpose, including as a client or server, and consumers must send
requests or responses that specify a chunk size greater than 18 exabytes. For a possible request smuggling attack to be possible,
any upstream proxies must accept a chunk size greater than 64 bits.

See advisory page for additional details.

I'm trying to get a feel for what the intent of this project is. I can't tell if it is intended to be 100% distributed like fossil, or if it is just intended to be another Github/Gitlab.

The reason I ask is because I would love to see something like fossil, but for git, so that I can share not only my code but all of my issues, discussions, kanban board, etc., etc., etc. I just can't tell if that's the direction you're trying to go with it.

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
• now

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.

Data race when sending and receiving after closing a oneshot channel

If a tokio::sync::oneshot channel is closed (via the
oneshot::Receiver::close method), a data race may occur if the
oneshot::Sender::send method is called while the corresponding
oneshot::Receiver is awaited or calling try_recv.

When these methods are called concurrently on a closed channel, the two halves
of the channel can concurrently access a shared memory location, resulting in a
data race. This has been observed to cause memory corruption.

Note that the race only occurs when both halves of the channel are used
after the Receiver half has called close. Code where close is not used, or where the
Receiver is not awaited and try_recv is not called after calling close,
is not affected.

See tokio#4225 for more details.

See advisory page for additional details.

Unsoundness in dashmap references

Reference returned by some methods of Ref (and similar types) may outlive the Ref and escape the lock.
This causes undefined behavior and may result in a segfault.

More information in dashmap#167 issue.

See advisory page for additional details.

GitArena makes a couple of outbound requests to external services (such as Gravatar). We should A
allow configuration of outbound proxies for each request.

aesni has been merged into the aes crate

Please use the aes crate going forward. The new repository location is at:

<https://github.com/RustCrypto/block-ciphers/tree/master/aes>

AES-NI is now autodetected at runtime on i686/x86-64 platforms.
If AES-NI is not present, the aes crate will fallback to a constant-time
portable software implementation.

To prevent this fallback (and have absence of AES-NI result in an illegal
instruction crash instead), continue to pass the same RUSTFLAGS which were
previously required for the aesni crate to compile:

RUSTFLAGS=-Ctarget-feature=+aes,+ssse3

See advisory page for additional details.

Lenient hyper header parsing of Content-Length could allow request smuggling

hyper's HTTP header parser accepted, according to RFC 7230, illegal contents inside Content-Length headers.
Due to this, upstream HTTP proxies that ignore the header may still forward them along if it chooses to ignore the error.

To be vulnerable, hyper must be used as an HTTP/1 server and using an HTTP proxy upstream that ignores the header's contents
but still forwards it. Due to all the factors that must line up, an attack exploiting this vulnerability is unlikely.

See advisory page for additional details.

SMTP command injection in body

Affected versions of lettre allowed SMTP command injection through an attacker's controlled message body. The module for escaping lines starting with a period wouldn't catch a period that was placed after a double CRLF sequence, allowing the attacker to end the current message and write arbitrary SMTP commands after it.

The flaw is fixed by correctly handling consecutive CRLF sequences.

See advisory page for additional details.

Groups (as called similiary on GitLab and called organisations on GitHub) are a namespace under which repositories and all their data can be stored without belonging to a specific person.

Currently this issue is low priority as for the start organisations can just create an additional user on GitArena under which they can host their projects. We will allow individual accounts to be turned into groups once they are finally implemented. (Similiar to how Sourcehut is currently [December 2021] doing it)

Probably allow login with the biggest VCS websites:

• GitHub
• GitLab
• BitBucket

and maybe popular web services such as:

• Google
• Twitter

TODO on the implementation details:

• Save avatars
• Save SSH and GPG keys
• Verify CSRF tokens

Currently disabled repositories are only hidden in the web frontend and not anywhere else. This needs to change for them to be fully inaccessible (except for administrators):

• Disable cloning and fetching from disabled repositories
• Disable API access to disabled repositories

libgit2 allows custom backends, should consider this with e.g S3

maybe gitoxide also provides such a backend?

Hi, I'm trying to run gitarena on my computer with a Postgres instance running on Docker.

docker run --name git-arena -p 5432:5432 -e POSTGRES_PASSWORD=password -d postgres

But I'm having this error: Error: Unable to initialize config in database

My DATABASE_URL variable is: postgresql://postgres:[email protected]:5432/gitarena

I am able to connect to this instance using psql, can you help me with it?

rustc --version: rustc 1.57.0 (f1edd0429 2021-11-29)
cargo --version: cargo 1.57.0 (b2e52d7ca 2021-10-21)
OS: EndeavourOS Linux x86_64
Kernel: 5.15.12-arch1-1

In the commits view, if you keep scrolling, the commits keep showing up.

I have a repository with 41 commits, I think there's a limit of 20 commits per page, but if I keep scrolling, it just keeps loading the same commits over and over, when it should load just 3 pages (2 of 20 commits and 1 page with 1 commit).

screenshot

stdweb is unmaintained

The author of the stdweb crate is unresponsive.

Maintained alternatives:

• wasm-bindgen
• js-sys
• web-sys

See advisory page for additional details.

This allows for an easier contribution workflow. This can be seen on GitHub in the form of pull requests or on GitLab as merge requests. It is important that GitArena additionally supports the usual decentralized mailing list workflow (git send-mail), similiar to Sourcehut.

These two features should support the following VCS: Git, Subversion and Mercurial

• Importing of repositories into a new Git repository on GitArena
• Mirroring of existing repositories into a new Git repository on GitArena (with frequent updates at configurable intervall)

For the later case, it is important to know how GitArena should handle conflicts (such as when code is changed on GitArena and then conflicts with a change that was pushed to the mirror). The following two solutions come to my mind:

• Make code in mirrored repositories read-only (but not issues etc.)
• Stop mirroring changes as soon as code has been pushed to the GitArena repository manually

I'm happy to discuss this and I'm open for suggestions.

I built GitArena from source code and tried to run it, but GitArena says, "Page Not Found".
Could you tell me how to fix this issue?

OS: macOS 13.3.1
Browser: Chrome 112.0.5615.49
Server: Debian 11.6
Rust: 1.68.2 (6feb7c9cf 2023-03-26)

Sled is an embedded database written in rust. This means that you don't need to have a connection to a running database instance, and can ship the database engine within gitarena. Not sure if this is good or bad, but it's an option to consider.

We should move common operations in routes to guards to cleanup the actual route body to restrict to mostly stuff that is also route specific. I thought the following would be good to move the following checks to a guard:

• User existance
• Repository existance
• Repository privilige
• Branch check

Idea suggested by @emily33901

Paste service for code snippets and other smaller files: GitArena Bin

Allow it to be scoped to either users, groups or specific projects with the three identifiers public, unlisted and private (only applicable on groups and repository scopes).

cpuid-bool has been renamed to cpufeatures

Please use the `cpufeatures`` crate going forward:

<https://github.com/RustCrypto/utils/tree/master/cpufeatures>

There will be no further releases of cpuid-bool.

See advisory page for additional details.

GitArena is currently lacking major parts of it's web frontend. The existing sites are also currently not very pretty and need cleanup. Help is greatly appreciated!

The following sites still need to be implemented:

• Home page (/, logged out view)
• User dashboard (/, logged in view)
• Explore page (/explore):
  • Standard page to view public & internal repositories as well as a few simple filters
  • Current activity (trending)
  • "Featured repositories" (configurable via admin panel)
  • Sort of like GitHub and GitLab
• Repository pages (/{username}/{repo_name})
  • Issues list (/.../issues)
    • Specific issue view (/.../issues/{nr})
  • Merge requests list (/.../mergers)
    • Specific merge request view (.../mergers/{nr})
  • Releases list (/.../releases, based on Git tags)
    • Specific release view (/.../releases/{tag_name})
  • Commit list (.../tree/{branch}/commits)
    • Specific commit view (/.../commit/{oid}
  • Specific directory view (/.../tree/{branch}/directory/{dir_name}
  • Specific file view (/.../tree/{branch}/blob/{file_name}
• Users view (/{username})
• ...

And many more! List will be updated once progress on existing pages has increased.

Out-of-bounds write in nix::unistd::getgrouplist

On certain platforms, if a user has more than 16 groups, the
nix::unistd::getgrouplist function will call the libc getgrouplist
function with a length parameter greater than the size of the buffer it
provides, resulting in an out-of-bounds write and memory corruption.

The libc getgrouplist function takes an in/out parameter ngroups
specifying the size of the group buffer. When the buffer is too small to
hold all of the reqested user's group memberships, some libc
implementations, including glibc and Solaris libc, will modify ngroups
to indicate the actual number of groups for the user, in addition to
returning an error. The version of nix::unistd::getgrouplist in nix
0.16.0 and up will resize the buffer to twice its size, but will not
read or modify the ngroups variable. Thus, if the user has more than
twice as many groups as the initial buffer size of 8, the next call to
getgrouplist will then write past the end of the buffer.

The issue would require editing /etc/groups to exploit, which is usually
only editable by the root user.

See advisory page for additional details.

I'd like to request FreeIPA and LDAP integration as a means of authentication on GitArena. Integration for this exists on other self-hosted git instances such as Gitea, GitLab and would likely be a used feature on GitArena.

aes-soft has been merged into the aes crate

Please use the aes crate going forward. The new repository location is at:

<https://github.com/RustCrypto/block-ciphers/tree/master/aes>

AES-NI is now autodetected at runtime on i686/x86-64 platforms.
If AES-NI is not present, the aes crate will fallback to a constant-time
portable software implementation.

To force the use of a constant-time portable implementation on these platforms,
even if AES-NI is available, use the new force-soft feature of the aes
crate to disable autodetection.

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.

Currently, GitArena only allows limited Git access over http(s). This should be extended to allow SSH access as well. This will probably be realized via a separate crate (gitarena-ssh).

Integer overflow in the bundled Brotli C library

A buffer overflow exists in the Brotli library versions prior to 1.0.8 where an attacker controlling the input length of a "one-shot" decompression request to a script can trigger a crash, which happens when copying over chunks of data larger than 2 GiB.

An updated version of brotli-sys has not been released. If one cannot update the C library, its authors recommend to use the "streaming" API as opposed to the "one-shot" API, and impose chunk size limits.

In Rust the issue can be mitigated by migrating to the brotli crate, which provides a Rust implementation of Brotli compression and decompression that is not affected by this issue.

See advisory page for additional details.

The commit list is supposted to be sorted by commit date, from newest to oldest. At the moment, it seems to be in a random order with seemingly no consistency.

Archived repositories have been introduced with 42eaa6d, which is supposted to make repositories read-only. This is currently not the case.

Basically all VCS are also a small scale social platform for developers and every social platform has some sort of "like" or "favorite" or "heart". GitHub and GitLab both opted for "stars" instead and GitArena should implement this as well. It is a interesting indicator to see the popularity of a specific repository.

With the majority of config values now being stored in the database, the admin panel should have the ability to change them.