higher (secret) phase semantic

[Pierre-Yves David]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 9 janv. 2012, at 20:28, Olav Reinert wrote:

> The name "secret" is disliked because to some it suggests enforcement of confidentiality (i.e., that it's safe to check in trade secrets or nuclear launch codes), which is not the case, and not intended, either.


An extensive discussion between  Matt Mackall, Benoit Boissinot and me took place Tuesday. We had conflicting initial version.

My version was: 

	Secret changeset are by default excluded of exchange but stay discoverable, pushable and pullable if needed.

Matt version was:

	Secret changeset are not exposed remotely at all.

The main reason I kept this stance was that I did not wanted to deny the user the ability to make exceptional exchange of a secret changeset when he really want too. The same way that mq prevent you to push patches by mistake but allow you to do it if you really want too.

But Benoit had the convincing argument that not exposing secret changeset to remote peer does not prevent to force the push of a secret changeset. As the push logic is executed locally, we have all necessary data and freedom to enforce the push of such changeset.

The only usage denied by the matt semantic is "pulling remotely secret changeset". I do not fell this usecase as critical (and even mainly agree with Matt claim that is should never be possible)


Patches shifting the implementation toward this stronger semantic is to be expected soon.

(note: Patching every possible disclosure of "secret" information will take some time and I expect some case not to be fixed for 2.1 (or even detected))

If you have valid and convincing usecase to allow pulling of secret changeset please talk now

**However**,

I *do aim* for an implementation where:

* Secret changeset are consistently hidden to a remote user.
* Protocol operation between client and server will not rely on secret related data to work.

I *do not aim* for an implementation which:

* do whatever possible to prevent any secret related information to be retrieve by a malicious client. (This of course will be avoid as much as possible)

Getting a perfect security is hard (if ever possible). There are several case where it will make perfectly valid operation much more complicated. In particular in case where remote can use the result of bundle push or pushkey operation to probe secret related behavior.

I do not feel like the jobs of ensuring strong security on **repository content privacy** fit mercurial well. In most security related topic, mercurial does let external actors handling this security (hgweb http auth, mercurial server, …). We are writting a Version Control System, not a security tool.

I expect this point to be the topic of a later discussion with Matt.

  ==

The willingness to change the phase name from "secret" to a weaker semantic still seems valid to me.

- -- 
Pierre-Yves David

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJPDpm0AAoJELAL+T1/FX64r48P/0T5SLAnDJclyhtatjP63l6f
dd/AqFUqsSa9UzNigc8k4VhPYP3zrGpW+SrXaumXpIKAk/G91M9MmbC3FukZCZ+z
xgF/w8KlwCphljw64nUx5i98cWQp3R8LQajkbX+WCD29DYyxR4FQ1zRobBLF5z2z
+9gJCRwko5DAm5rct3JDVL7tWt/mzzW1Hhxyrzfn7mQGby9LOPQrJwb0BOgOFBQd
BDnzGT4g7EaLcYK2lwg+aBIUkniFyKfcGKZtqNf27LZRKcBKmpstjRSTO+NML7eO
HRF3rp6hQhDB49kKELn00q3NlxquE5emuusZytT+A/oNRv9dE4Q9ZdE8ni9dIWpZ
uy2yaVjA6+FOj12fN8fH8SYyKLAavrI66IaX3WuvyhAy+6HrnxQZvjK04zdWIBEz
gFpaxsiZJSFnAD5j2yBRzT85ymYPBq9ic77GamCP4SUwsAo+b5gMTL5ZMJx4kGLc
cLDuBqeePhO30etcOFvV+O+nOxmlDCb2N90BxbP1UhkN4mys2EI0NhBRUmUZEIXW
Zg6MHq0yieZOtQVbymqHkrwhsWoU83KhMwSNyytYeA6FErNgvzJiwL9bfWU6TMYL
tEngp7GwH7pdxsDA7FIdyK7k00/ZmSeDswo7yN4dd1A1J8mpZsNONvVcE4kTEnqO
8toqJW4h3w7EkK3yK/q1
=btDx
-----END PGP SIGNATURE-----