I have a "central" Mercurial repository, which configured to use HTTPS and requires authentication to clone-pull-push changes. Developers has their own repositories on their computers. They configure their local settings freely, and for example add section like
[ui]
username = anyname
to their local mercurial.ini file.
When a user try to push his changes to the "central" repository, he authenticates, but authentication info is not stored in Mercurial. Mercurial store locally configured username as revisions author in central repository. So I cannot find who really made changes in central repository, but I strongly wish to do it. Mercurial developers does not care about it and consider this behavior to be correct.
But I want to keep authentication info near changesets. I think the best way to do it is add one more additional field in revision description, like "pusher id" and store there authentication data.
Extensions I found do not implement similar functionality. Can you give me info about some third-party extensions, hooks, or just code templates or ideas how to do it? (I'm absolutly new in Python)
The fundamental problem that makes Mercurial developers (like myself) reject this is that changesets are immutable. It is impossible for a server to add extra information to the changesets when they are pushed.
More concretely: a changeset is identified by it's changeset hash. This hash is computed based on all the information the changeset contains, such as username, date, commit message, and the change itself. You cannot change any part of this, without also changing the changset hash — otherwise the integrity of the repository is destroyed.
This gives you security against accidental (or malicious!) changes made on the server: if Alice and Bob talk about "changeset X", then they can be sure they really mean the same thing. If the server (or someone else) could change the content of a changeset without affecting the ID, then Alice and Bob would not be guaranteed that "X" really means the same
thing in both their repositories. This property is of course also fundamental to the way Mercurial works when synchronizing repositories.
You have two options here:
You can let the server reject a push if Alice tries to push a changeset with Bob's name in it. This is can be done with a pretxnchangegroup hook on the server. It will inspect the HG_SOURCE environment variable and verify that the user listed there is also the committer of all pushed changesets between HG_NODE and tip.
You can let the server log the pusher. This is called a "pushlog". The Mozilla project uses one and the source appears to be here. There you make your server store information about who pushed what. This is done in a changegroup hook that logs the necessary information in a small database.
If you want a push log, then take a look at Kallithea, which has this functionality built in. Kallithea is in general a great way to host Mercurial repositories! It has much more functionality than the normal hgweb CGI script.
Related
I am using KeyCloak as my user management tool, and love it.
The data of Keycloak is stored for me on a Postgres database. Over time, more clients are being registered, and other alterations to the realms may be done. My question is: How do I properly keep track of that, and propagate automatically changes between my different environments? For databases, I use liquibase for a purpose like this. I couldn't find anything similar for the Keycloak case.
So, I wanted to ask: How are you folks out there handling this? What am I missing?
It depends on how you're doing the management of those changes. There are generally two approaches:
Using the Keycloak admin console
Using the Keycloak CLI
If you're applying your changes via the admin console, then you can either rely on the database backup or setup a scheduled pipeline in your CI tool to make an export of the Keycloak realm into a file and archive it somewhere.
In case you're using the second approach, then you can have a git repository containing all the Keycloak CLI scripts that you run on your server (e.g. to add a client, to update a realm config, etc.). In that case, you can have them reviewed, versioned and then run as part of an automated pipeline. This will also allow you to run a script on different environments. But of course it comes with a price which is to write a script for every single task that you can typically do in admin console with a couple of clicks.
I have a program which looks for a config.json file where it reads needed sensitive infos like DB creds, different APIs creds, etc. I don't upload the config file to the git repository because I understand it's a bad approach, although it's a private repository. Now I'm starting to fear the case that I by accident delete this file, or due to a failure in my machine, I could permanently lose it. My question is - what is the best approach I could use to have a constant secured backup for this file, considering that it may contain very sensitive informations?
Also I would like to specify that this config file is frequently changed (and may increase in size...).
Select, implement, and test a backup system that meets your requirements for securing sensitive data. Access controls to the backup system, encrypting backup media, and logging jobs run are fundamental features to manage data.
Storing secrets in version control like git is tempting. But beware, a git repo may be cloned to many places, and every copy contains your credentials forever. Deleting them permanently requires rewriting history. Possibly easier to change any creds that got committed, leave the old ones in history, and don't commit secrets in the future.
Think about how you want to manage secrets. Secrets management software exists that wraps creds and keys in strong authentication and encryption. Building the application server could involve installing the application, and retrieving the API creds via the secret server. It may suit your needs to have different systems to store automation scripts, secrets, and backups.
Im using gitlab, and I am wondering, is there a simple way to restrict access to a branch to only certain developers? This has to do with time varying disclosure and the ability for certain developers to see some objects models, while other cannot? Ideally this would happen in one repository, without a proliferation of forks.
No, it is not possible to have a read protection to certain git branches. That would also defeat how git works.
What you could do is forking a repository, creating a branch here and only grant restricted permission to the entire repository. Later it would always be possible to merge changes from this forked repository to the original repository.
You can only change read access to the entire repository as well as write permission to branches.
We in our team are planning to use gerrit. So, to get introduced, I did set up a server, used open-id for authentication and created some test-users and test-projects in it.
Now we are ready to use it. But we actually prefer LDAP for real use.
So, can I change my authentication system from open-id from LDAP? What will happen to current users then?
I want to clear test projects and changes. How can I do them?
Can I complete delete existing gerrit setup and initiate a fresh setup in same machine? (I tried extracting the jar in different folder, but I faced some problems in it)
I am using Ubuntu 12.04 as my server.
Please help.
Delete the database (you're not using the H2 database anymore, but some MySQL or PostgreSQL server, don't you?) plus the directory where Gerrit is running (the -d parameter, see docs). Additionally, remove the git repos, if you configured them to be located on a different path.
Then all your data is gone and you can start from scratch.
I'm investigating using Mercurial in a corporate environment. The plan is to use central repositories hosted by a webserver (IIS) which developers will push to once they've tested changes locally or within their teams.
I have IIS configured to authenticate users against Active Directory, but there seems to be a hole in that while I can enforce who can push, I can't enforce that they sign their changesets as themselves.
For example, given a basic "commit" scenario:
user commits to their local repository
user pushes their changes to the central repository
In step 1, the user provides a username (via their .hgrc file or whatever) to their local repository, but there isn't really any way to enforce that this is their "real" username.
In step 2, the user has to provide their "real" credentials to IIS to be allowed to push, but their changesets will show up in the history with whatever username they provided in step 1. It seems like if bob used "alice" as his username for step 1, he could make sure alice got the blame for any of his buggy changes.
Is there a way to make sure these user names match up during the push (via hooks or something)? Or alternatively, some other way to ensure a reasonable level of authenticity in the change long?
Edit: On further consideration, I guess I don't actually want to enforce that these names line up; if Bob and Alice have been collaborating in a separate repo, Bob should ultimately be able to push all of their changes, not just his own. What I really want is just to make sure that if it comes down to it, I can tell who made what changes in a more definitive way than just whatever username was applied.
I'm thinking GpgExtension is part of the answer, but I still don't think I've got the full picture.
I eventually found this discussion, which essentially says that my options are essentially getting everyone to sign changesets with GPG, or setting up a "pushlog" outside of mercurial which tracks what user pushed what to the central repository.
Ry4an also pointed out this (essentially duplicate) question with some good answers that confirm what I'd found elsewhere.