5,444 karma · joined March 21, 2009
[ my public key: https://keybase.io/bcl; my proof: https://keybase.io/bcl/sigs/EuBaToikfP2PZZVfG9z8uCU2-S0HhHwBSVguHQOjtKk ]
push "redirect-gateway" push "dhcp-option DNS 8.8.8.8"
If he doesn't know who started it, how do we know the money will actually get to him?
it looks like it has been re-factored somewhat, although the lock is still in there.
https://admin.fedoraproject.org/updates/openssl-1.0.1e-37.fc...
https://admin.fedoraproject.org/updates/openssl-1.0.1e-37.fc...
When working with more than 0 other people you should reserve the upstream branches for merging your work and pushing. Do your actual work in a branch and you can easily commit/stash our working tree, switch to the other branch and examine their changes.
1) packagers have a history with their packages. They fetch from the same source, verify with the existing GPG key, etc. They aren't fetching from a different random source for each build. As part of the package review process the upstream source should be reviewed and confirmed.
2) Everyone in the distribution is using the same code. Unlike Windows/OSX the users get the same binaries from a single source. This allows problems to be corrected quickly for everyone at the same time.
I find it hard to believe that this code had a proper peer review before being committed. A 2nd and 3rd set of eyes experienced at reading C should have spotted this. Peer review is especially important when dealing with core security components like this where simple mistakes can have huge consequences.