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.
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.
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.
I have various projects being built and tested periodically on a Hudson server, but I don't want every employee in the company to see published artifacts for every project.
Project-based matrix security seemed at first the key, but after many tests I find that granting overall read permissions is mandatory if you want users to be able to read anything in the hudson server.
So, in the end read permissions are binary: either you grant global read permission or you block everything, am I right?
Haven't it tested with the newest release, but I use the matrix setup. I gave Anonymous the overall read. This way they can see the login screen when they type {{http://servername:port/}} but does not give them access to the jobs. In the jobs themselves I configured the users that should actually see the job. Works like a charm.
UPDATE:
Meanwhile I found out that you can use authenticated instead of Anonymous. This enabled access to Hudson/Jenkins through the links in the Build failed messages. Now everyone gets the logon dialog and after signing in, they are right away at the job run of interest.
After trying to do something similar to you with Hudson's authorization settings, I came to the same conclusion you did.
I'm afraid I know the answer to this but I'll ask on the longshot chance that I'm wrong:
I've been doing some freelance work creating an iPhone application for a company. They've created their own developer account and added me as an team member with "admin" rights. That seems to be the highest assignable rights (with the only higher level being "agent" and belonging only to whoever signed up for the account). Yet, I don't have an option under the provisioning portal to create a distribution certificate or profile.
Is there any way to create these myself without having to ask my client for their primary login? They're not particulary tech savy so it would be difficult to walk them through the process to create the necessary certificates (and would require me giving them a certificate request from my computer, etc. etc.). But it seems like there should be some way to create a distribution build without "agent" rights, right? Could Apple seriously expect only one person from a company to do all the building and uploading of apps to the store?
You are right. Only the agent can create a distribution profile and a distribution certificate. There is no way around that. The easiest thing to do is work with him/her to create the key and certificate for distribution and install a copy of both on your machine as well. They are also the only one who can submit the binary on iTunes Connect.
It is annoying, but that's the way the final build must work - done by the team agent. I ended up getting my boss's login info. Switching team agents is also hard. IIRC, you can't be the team agent on two separate accounts.