Supposing there were 3 or 4 developers using Mercurial, and all making updates to a project. Right now, usernames are self-configured.
If I pull changes from a colleague, (which may include other changes he pulled from a different colleague), how can I be sure the usernames on each commit actually were authored by that user, and not a different user who might have entered a fake username on that commit?
I assume Mercurial has some solution for this problem built in, perhaps using cryptography to compare the username to the hash and private salt or key or something.
Is there a way to validate authors for each commit? How does this work, and is it possible to do this whilst maintaining the Distributed nature of our Version Control System, or will we need an authenticating server?
You use the GPG extension.
That means you are using an OpenPGP system, and all that entails.
There is a discussion, about the past, present and future of signing.
Related
I am developing a library to edit contacts on a CardDAV Server and I wonder what is the proper way to sync contacts.
So when I find an etag for a specific contact changed: How do I sync both?
Do I just combine the changed data, e.g. phone numbers? Or must one side (Server or client) win? And how to I detect if a number changed or was added?
The Building a CardDAV client document explains all this very well.
But to address your questions:
So when I find an etag for a specific contact changed: How do I sync both?
You load the vCard from the server. Then it depends on the logic of your client. Do you want to auto merge? Do you want to prompt the user whether he wants to merge? Etc.
Usually you want to auto-merge. So do this. After you have the merged vCard, PUT that again to the server, but make sure to use the If-Match header to ensure that it didn't change again on the server side.
Do I just combine the changed data, e.g. phone numbers?
What you consider useful is entirely up to your application. But just combining fields may not be what you want. For example you wouldn't be able to detect deletes.
So in most cases this is going to be a three-way merge:
old version of the server (stored locally)
new version of the server (that you just fetched)
current version of the local application
Or must one side (Server or client) win?
Some clients do it like that, but this is not required. However, if you modify after a change, you need to be VERY careful with sync cycles!
And how to I detect if a number changed or was added?
You store the old copy you know and diff.
In general it is a good idea to store the (last known) opaque server copy locally and just pick out the fields your client cares about. Then when uploading the item again, you just patch the ones again. (and preserve the rest of what the server sent you).
Summary: A proper vCard diff and local cache is non-trivial. Many clients fail on that and loose or dupe user data.
So unless you plan to put the necessary work and testing into this, an easier way is to detect the changes and ask the user what he wants to do (let server win, force user copy, merge).
I'm using Play 2.1.x and I'm wondering if there is a way to encrypt passwords that might be needed for database access? I have a configuration entry that stores the database server url, user credentials for accessing the database and I do not want to leave my password as plain text. How can I have my user credentials encrypted? I want to later un-encrypt when I use them within the context of my Play server. Any pointers?
The problem is where would you store the decryption key. If you store it in the same (or similar) configuration file, the entire exercise is moot.
I am guessing that you do not want to put the plain text password in application.conf to avoid having it show up in version control system. One way of mitigating that kind of leak is to have a different store for sensitive configuration files for production systems (a different repository that has fewer accessors works nicely).
i am making a business application and i cant afford other activation software to protect my software from being pirated. I am looking for some place to save my activation, trial and licence data in user's computer.
I think that if i use compact editions of sql server and give password to it, it will be impossible for any other hacker or cracker to modify activation data and pirate my software? Is this safe or i shoul go for anyother option?
First, you must realize that making it 'impossible' to crack has been tried and tried again by the largest corporations and most sophisticated products- and it has always failed.
Having said that, you can make progress towards encouraging your customers to purchase a license by using a password protected encrypted database, password alone is not enough.
Also, what do you plan on using for your password? Is it going to be hardcoded? Will you salt a hardcoded pwd with something unique to the system its running on? Will that be good enough, I'm assuming if thats all you do breaking it would be fairly trivial- disassemble your code and find the hardcoded password, and figure out how you compute the system unique value.
Please take a look at this other similar SO Question and its answers- some are quite good.
(I am newbie to tortoise SVN)
I have 2 folders in my tortoise SVN.
Each need a different set of authorization
(I do not want
people who have access to the first folder to have read / write access to the second folder).
How can I accomplish it? I noticed that all permissions are defined in a file in the root level.
This is covered in the Subversion Book section on Path Based Authorization. You can check out the link for more details, but I would just draw your attention to this part:
A lot of administrators setting up Subversion for the first time tend to jump into path-based access control without giving it a lot of thought. The administrator usually knows which teams of people are working on which projects, so it's easy to jump in and grant certain teams access to certain directories and not others. It seems like a natural thing, and it appeases the administrator's desire to maintain tight control of the repository.
Note, though, that there are often invisible (and visible!) costs associated with this feature. In the visible category, the server needs to do a lot more work to ensure that the user has the right to read or write each specific path; in certain situations, there's very noticeable performance loss. In the invisible category, consider the culture you're creating. Most of the time, while certain users shouldn't be committing changes to certain parts of the repository, that social contract doesn't need to be technologically enforced. Teams can sometimes spontaneously collaborate with each other; someone may want to help someone else out by committing to an area she doesn't normally work on. By preventing this sort of thing at the server level, you're setting up barriers to unexpected collaboration. You're also creating a bunch of rules that need to be maintained as projects develop, new users are added, and so on. It's a bunch of extra work to maintain.
Just to round the post of codeka up. You can't set (at least I never have found out how) any permissions for the repo in tortoise as it is the SVN client application. You would have to set the permission on your svn server. If you happen to be running VisualSVN Server (free) you can setup user rights in a windows-easy manner (point and click).
Hai guys,
I ve developed a salary calculating software using vb.net.... Its working fine and i ve converted it to an exe file... My drawback is it can be copied and pasted in another system very easily... I want to generate a key for the exe file and while installing the key should be used and when installation is completed ,the key should not be used again... Is this ya secured one or give me some ideas how it can be done....
There are many product on the market that will help you generate software keys, for example www.softwareshield.com and www.exeshield.com Or simply do a Google Search.
For more serious protection you can use a hardware key that unlocks your software, for example http://www.matrixlock.de/english/index.htm
It all depends on your adience.
If you are targetting end-users / home-users: no matter what you do, your software will be hacked (if it is good enough).
If you target the enterprise: Companies are mostly willing to buy your software, and do not copy to other companies. They have far more to loose when running illegal software. But also they are the first to complain if they cannot distribute your software using their distribution system. And this system will be blocked by your copy protection scheme.
Conclusion: Implement the simplest and cheapest protection scheme you can find. And also find a way you can bypass it easily if you want enterprises as your customer.
You'll need to sign your assembly, and have some form of online authentication process to manage the keys.
Whatever copy protection scheme you implement....just make sure that your paying users don't get a lot of discomfort from it.... You want to keep bad users from copying your software without permission, but when good users get problems because of faults in your copy protection software, you will lose a lot of credit.