Announcement: i2pgit.org migrating away from gitlab, digitalocean

[eyedeekay]

Your attention please:

In the next month, i2pgit.org/git.idk.i2p will be drastically changing.
This includes hosting, software, and policy changes.

## Timeline

- Gitea Online Goal Date: March 16
- Gitlab Offline Goal Date: April 16

The time period from Feb 16 to April 16 is the "overlap period" where both services will be running.
This is the time to to download your repositories, backup your issues and MR's and set up alternative hosting if necessary.
I2P team members will be given namespaces on the new server.
Since the team is loosely structured and community-based "team members" is also somewhat loose.
Generally, if you contribute code to projects in the i2p-hackers namespace, develop a client library, or filed at least one issue where you included relevant logs, then you'll get a namespace if you ask.
If you don't know, ask.
As before, new accounts are approved at the discretion of the git admin(me).

## Policy Changes

Most notably, i2pgit.org will no longer host projects outside of the I2P dev team.
If you are hosting projects on i2pgit.org, now is the time to move them somewhere else.
You have are many options, including self-hosting your own git service.

- Implications for Users: If you are not a regular participant in I2P, I2P+, go-i2p, or i2pd development, your repositories **WILL BE DELETED** after the migration.
- Back up and mirror your repositories before the migration occurs.

## Hosting Changes

After several years of service, DigitalOcean is no longer a great fit for this git server.
We will be moving the i2pgit.org server to StormyCloud's VPS infrastructure.
StormyCloud will be able to provide us with a more suitable allocation of hardware which is a better fit for git hosting.
Thank you to DigitalOcean for the past few years of service and support.
Thank you to StormyCloud for your dedication to I2P service and support and your offer to assist during this migration.

## Software Changes

With the policy changes comes a a software change as well.
We will be migrating from Gitlab to Gitea.
Gitea has a much smaller footprint, simpler configuration, and lower maintenance burden than Gitlab.
It is also possible to build a modded, self-configuring Gitea for I2P.
The in-I2P address of I2P Gitea will be the same as I2P Gitlab, git.idk.i2p

- Implications for Users: If you are a regular participant in I2P, I2P+, go-i2p, or i2pd development, your repositories are allowed after the migration.
- I can mirror the repositories for you if you wish, or you can do it yourself.
- I will send you an invitation with a password reset option in order to provide you with a Gitea account.
- I will send you mirroring instructions along with a script if necessary.

Gitea operation for users is almost identical to gitlab and github.
All the ways we use Gitlab(Issues, Merge Requests, Milestones, etc) have one-to-one equivalents in Gitea.
There should be no significant learning curve.
Gitea is also easier to use without Javascript.
In general it should be a better fit for us.

### What about CI

Currently our in-house CI works using Gitlab runners.
We also run fairly extensive CI on Github, notably, all Gitlab CI jobs in the i2p.i2p repository are repeated on Github Actions.
We will continue to use hosted CI during the transition, and will switch to another CI tool(likely drone.io) for in-house CI.

[eyedeekay]

This is taken from https://github.com/go-i2p/go-gittisane, where I continuously build a modded version of gitea which automatically works with I2P.

go-gittisane

A soft-fork of gitea with support for running as an I2P service. Just the mod and the CI files.

How it works:

This uses GitHub CI to continuously build an I2P-only version of Gitea based on the latest release of Gitea. We can do this without requiring a patch to the Gitea source code. This is because Gitea encapsulates its "Listening" and "Dialing" into functions, which can easily be substituted for alternative versions. For instance, the network listener is set up by a function, `graceful.GetListener() (net.Listener, error)` in the file `modules/graceful/server.go`. The default implementation of the `GetListener() (net.Listener, error)` function, `DefaultGetListener() (net.Listener, error)` is defined in the `modules/graceful/net_unix.go` for Unix-like systems and `modules/graceful/net_windows.go` for Windows-like systems. A developer who wishes to "Mod" gitea to listen on another kind of connection do so by creating a new file which implements a `GetListener() (net.Listener, error)` function using an alternate listener implementation.

On the client side, the same thing is possible because Go allows you to substitute the underlying transports used for the default HTTP Client. So, in the absence of overriding settings, we can configure it to use SAMv3 to build HTTP connections by default using the same keys as the hidden service. Effectively this is like a "Bidirectional HTTP" tunnel in Java's Hidden Service Manager.

Finally, if you need to include additional libraries, run `go mod tidy` in the root of the gitea checkout to include them.

Here is a complete working example mod:

Code: Select all

// copy this file to modules/graceful/net_anon.go before building gitea
package graceful

import (
    "net"
    "net/http"

    "github.com/go-i2p/onramp"
)

// First, make sure that the onramp.Garlic API is set up:
var garlic, i2perr = onramp.NewGarlic("gitea-anon", "127.0.0.1:7656", onramp.OPT_DEFAULTS)

// This implements the GetListener function for I2P. Note the exemption for Unix sockets, which is implemented in net_anon_unix.go and net_anon_windows.go
func I2PGetListener(network, address string) (net.Listener, error) {
    // Add a deferral to say that we've tried to grab a listener
    defer GetManager().InformCleanup()
    switch network {
    case "tcp", "tcp4", "tcp6", "i2p", "i2pt":
        return garlic.Listen()
    case "unix", "unixpacket":
        // I2P isn't really a replacement for the stuff you use Unix sockets for and it's also not an anonymity risk, so treat them normally
        unixAddr, err := net.ResolveUnixAddr(network, address)
        if err != nil {
            return nil, err
        }
        return GetListenerUnix(network, unixAddr)
    default:
        return nil, net.UnknownNetworkError(network)
    }
}

// We use `init() to ensure that the I2P Listeners and Dialers are correctly placed at runtime`
func init() {
    if i2perr != nil {
        panic(i2perr)
    }
    GetListener = I2PGetListener
    httpClient := &http.Client{
        Transport: &http.Transport{
            Dial: garlic.Dial,
        },
    }

    http.DefaultClient = httpClient
    http.DefaultTransport = httpClient.Transport
}

Caveats

Gitea makes a few other kinds of connections, besides `HTTP`, if instructed to do so in the config file. For instance, there is an SMTP client. This is not anonymized in this configuration. Probably ask Postman if it's OK to use `127.0.0.1:7659/7660`. Similarly, SSH client connections are not anonymized in this configuration. Similar adjustments to the configuration can be made to also route these across I2P but aren't documented here at this time.

License

Both this mod and gitea are licensed under the MIT license. See LICENSE for net_anon*.go in this repository. LICENSE-gitea.md is a copy of the Gitea license from https://github.com/go-gitea/gitea

[eyedeekay]

All right everybody you're getting one more week, then i2pgit.org will be a gitea instance instead of a gitlab instance. Just in time for me to get it switched ahead of my last hosting bill. The official last day for any gitlab access will be the 22nd.

[eyedeekay]

The vast majority of gitlab accounts have now been deleted. If you still have an account it's because you had activity in the past 2 years, more than 3 repositories which were not spam, or which were from known contributors.

You may continue to use gitlab to work on issues and merge requests. I'll sync any changes back manually. The gitea instance is and running, the URL has been shared with a few people so far. DNS will be switched over on the 21st, at which point the gitlab instance will be shut off at last and the gitea instance will take it's place.

[eyedeekay]

Hello I2P Team and Community,

We have now mostly completed our migration to from Gitlab to Gitea.
Gitlab is great for some people, but not for us.
It was difficult to maintain and keep up to date, made extensive use of in-browser javascript and websockets, and was generally just a little but difficult to use inside of I2P.
While Gitlab's feature-set is commendable, Gitea is a better fit for us.

The new Gitea instance is currently usable inside of I2P.
It is not currently usable on the clear web, because I accidentally hit the Let's Encrypt rate limiter last night and we have to wait.

There are a few differences, but nothing that should slow you down.

- TLS: TLS is no longer required to interact with the web interface(no more complicated websocket stuff).
- On the registered hostname, use http://git.idk.i2p from now on.
- If you still wish to use TLS, use https://57z3ffssd34lztr2dgkddqd36sdn73l ... ea.b32.i2p instead
- Email: Instance email works again!
- From now on(for instance, in about 2 minutes) you will receive email from the gitea instance from my email address
- Expect the email to come from: `idki2p@mail.i2p` or `idki2p@i2pmail.org`
- Merge requests are not migrated yet(To pull requests, which is what gitea calls them). Feel free to re-create merge requests you want me to get to right away, but use **exactly** the same title when entering the pull request so the migration tool does not duplicate the issue when I run it to migrate the remaining MRs.
- You will need to remove old entries for git.idk.i2p, i2pgit.org, and git.i2p.net from your ssh known_hosts file.

And, most importantly, passwords.
You will need to generate new passwords.
I don't have GPG keys for everybody so I do not want to send you your temporary passwords.
Instead, you should initiate a password reset.

To do this:

- Open [The password form](https://57z3ffssd34lztr2dgkddqd36sdn73l ... t_password) in your browser
- Enter the email you used to register for gitlab. This will be the same email address where you received this message.
- Click "Send Account Recovery Email"
- Open the email and click the link.
- Enter a new password.

That's it. Please contact me if you notice anything wrong or need any help.

Thanks for your time,
idk

[eyedeekay]

Typically, to remove the ssh host keys, use the commands:

ssh-keygen -f "$HOME/.ssh/known_hosts" -R 'i2pgit.org'

ssh-keygen -f "$HOME/.ssh/known_hosts" -R 'git.idk.i2p'

ssh-keygen -f "$HOME/.ssh/known_hosts" -R 'git.i2p.net'