Is there a way to protect oneself from Mercurial identity theft?
The case is if someone deliberately commit bugs into the code using another developer's name with the goal of getting that person fired or mis-credited.
Is there a way to stop that from happening or is it a non issue?
I don't know a way to actually restrict the commits not so include a "stolen" identity, but if you have a centralized repository you should be able to securely audit who has pushed which changes to the server, and thereby track down the identity thief.
Edit: there seems to be support for signing commits with two extensions, the CommitsigsExtension as well as the seemingly less secure approach implemented by the GpgExtension.
Signing the changesets effectively prevents identity theft since the thief does not have the private key of the identity he wants to steal, thereby he cannot sign the commit.
The Mozilla project does this in the form of a pushlog. They made a trivial change to the web templates to show the output of a pushlog which is easily created at push time using a changeset hook. Here's what their log looks like:
http://hg.mozilla.org/mozilla-central/pushloghtml
A hook that creates such a log could be as easy as:
[hooks]
changeset = echo $REMOTE_USER pushed HG_NODE >> /path/to/my/pushlog
In practice this is one of those things that everything thinks will be a problem when they first hear that the "user" field is entirely falsifiable, but in practice is just never actually a problem.
Use access control on the "main" repo and log requests. If you log who authenticated to push each commit, you can tell who really pushed a particular commit, regardless if the info in the repository.
Related
I recently moved some of my repositories from AWS Code Commit to GitHub. I accidentally made one of the repositories public, instead of private. Within less than 10 mins of committing the code, I got an email from Stripe that my secret key is publicly accessible, and it included the exact file/code line which has the key.
How did this happen?
Does GitHub detects existence of some sensitive info and informs the provider via some WebHook?
Does Stripe keeps crawling new repositories for such leakages? It sounds practically impossible to detect so quickly.
I cannot get my head around what could have triggered this detection at Stripe's end. I was thrilling to see the action though. Of course I have rotated the secret key.
We had a developer submit a PR that had a plain text password in it. The reviewer asked it to be removed and loaded in another way so it didn't make its way into the repo. It has since been fixed. However, the history of the PR still shows the original commit with the password. Is there any way to remove a portion of the history of the PR (or if necessary the entire PR) so that other users cannot view that password?
If there isn't a supported answer, we happen to be using AzDev 2019 server, which I believe should enable us to remove it somehow...
Note in this case we can just change the password, so this isn't a deal-breaker, but it would be nice to know how to do this for future occurrences where changing a password is more difficult.
It's not able to delete a Pull Request at the moment in Azure DevOps Sever.
We already have a user voice in Develop Community feature request site. Kindly vote up and track the status.
Allow deletion of pull requests
https://developercommunityapi.westus.cloudapp.azure.com/idea/365572/allow-deletion-of-pull-requests.html
If you hadn't commit the pull request, we give an option to abandon the pull request which leaves them hanging around.
This should be a team process policy to avoid users commit plain-text password. Changing the password, that's the safest option.
I see your point but the rule of thumb is - if password was exposed you should revoke it asap.
You can also try this:
To replace all text listed in passwords.txt wherever it can be found
in your repository's history, run:
$ bfg --replace-text passwords.txt
I was looking at REST API for Pull requests, but there is nothing about removing it.
I have encountered a similar problem and one solution could be to remove the repository in Azure which would remove the history as well. So fixing the issues locally then creating a new remote repo for the branch would be a way to go.
I have Travis-ci on a public repository. After finishing the execution it generates a image that I want to upload to cloudinary.com, but it could be any other service.
The problem is that to do it, I need to add in .travis.yml the auth token. But I don't want to expose it publicly, and for that travis offers a way to secure Env variables: http://docs.travis-ci.com/user/environment-variables/#Secure-Variables. However they do not work on PULL requests:
Secure Env variables are not available on pull requests from forks due
to security risk of exposing such information to unknown code.
Encryption and decryption keys are tied to the repository. If you fork
a project and add it to Travis CI, it will have different keys to the
original.
Anyone has any idea about how could I add an hidden value that is available for PUSH and PULL REQUESTS?
As you already wrote in your question: according to the official Travis CI documentation https://docs.travis-ci.com/user/environment-variables you won't have access to these variables from untrusted builds such as pull requests. This makes sense, since someone could submit a pull request to your repository containing malicious code which then exposes your secret value.
Bottom line: if you want to make secret values available to pull requests, you have to assume they're not secret anymore - therefore you could also just hard code the unencrypted value to your .travis.yml and use it from there. Which doesn't seem like a good idea. ;-)
Possible solution in your case: you could just use an image hoster which provides anonymous uploading? You wouldn't need an auth key, so your pull requests would be able to upload, too.
I've got Mercurial running on IIS7 fine. One thing that is frustrating is that allow_push will only take a list of usernames rather than a group.
To that end, I was wondering if it'd be possible to use a hook to carry out this task. i.e. by passing in the authenticated username, you could check on demand whether the user has the appropriate access. That's all fine if you can pass the username into the hook, for example:
[hooks]
prechangegroup = echo %username%
Unsurprisingly, this always returns the account that IIS is running on. Is there a way to either get allow_push to respect groups - or to pass the logged on user into the prechangegroup hook?
Alternative approaches welcome.
This isn't ideal - and I'd rather do as above. The alternative approach I've taken is to have an external process set the permissions on the folders in IIS for read and execute, allow_pull and allow_push in the hgrc for the repository as appropriate.
In terms of shortcomings:
Its another process that needs to know about the location of the repository.
The process needs a mechanism to find out about updates to the groups (i.e. polling).
Is it possible to write some manner of hook in mercurial that will reject changesets that effect a specific named branch in a repository?
We have a managed project and would like to allow any developers to push their changes to our repository so long as they are in their own named branch. This allows us to manage a single buildbot and a shared sandbox in the same repository (by keeping branches separate). We'd like to block any attempts to write to the default branch from outsiders (we would, internally, merge their branches over).
We're looking at using the pretxnchangegroup hook, but this has 2 concerns:
1) A user can push changes using any username; we basically only have an http-auth protecting the repository by requiring any username or password to actually connect to the repo, but it doesn't check the usernames in the commit to make sure they match the account used to push.
2) Lets say a user has done right and developed in a branch, but then they do one last commit on the default branch. The hg push fails. What does the developer do at this point to fix their push?
Any thoughts?
Yeah, you can do this pretty easily with the pretxnchangegroup like you figured. I'll do it in shell, but it'd be in-process (and thus faster) if you do it in python.
Set up something like this as your pretxnchangegroup:
#!/bin/sh
for thenode in $(hg log -r $HG_NODE:tip --template '{node}\n') ; do
if [ $(hg id --branch -r $thenode) = "default" ] ; then
echo Commits to default branch are not allowed -- bad changeset $thenode
exit 1
fi
done
That makes sure that none of the arriving changesets are on branch "default".
Regarding concern 1: If you're running behind apache you'll have access to the usual CGI variables, so you can check $REMOTE_USER to make sure it matches the branch name if that's something you want to try to enforce.
Regarding concern 2: If a user sees the message that they're pushing an invalid changeset, then they'll just have to push the rest of them using push -r and they can strip or modify their changeset on default later.
Lastly, have you considered just having a separate clone for the auto-builds / main branch? Let everyone push into the staging repo, and let only the buildmaster pull approved changesets from staging into auto-build when s/he is happy with them? You get the same workflow you have now (waiting for a builder to merge), but it's much less hassle.