##// END OF EJS Templates
upstream » mercurial-mirror
RSS

Clone from https://www.mercurial-scm.org/repo/hg-all

sslutil: abort when unable to verify peer connection (BC)...
sslutil: abort when unable to verify peer connection (BC) Previously, when we connected to a server and were unable to verify its certificate against a trusted certificate authority we would issue a warning and continue to connect. This is obviously not great behavior because the x509 certificate model is based upon trust of specific CAs. Failure to enforce that trust erodes security. This behavior was defined several years ago when Python did not support loading the system trusted CA store (Python 2.7.9's backports of Python 3's improvements to the "ssl" module enabled this). This commit changes behavior when connecting to abort if the peer certificate can't be validated. With an empty/default Mercurial configuration, the peer certificate can be validated if Python is able to load the system trusted CA store. Environments able to load the system trusted CA store include: * Python 2.7.9+ on most platforms and installations * Python 2.7 distributions with a modern ssl module (e.g. RHEL7's patched 2.7.5 package) * Python shipped on OS X Environments unable to load the system trusted CA store include: * Python 2.6 * Python 2.7 on many existing Linux installs (because they don't ship 2.7.9+ or haven't backported modern ssl module) * Python 2.7.9+ on some installs where Python is unable to locate the system CA store (this is hopefully rare) Users of these Pythongs will need to configure Mercurial to load the system CA store using web.cacerts. This should ideally be performed by packagers (by setting web.cacerts in the global/system hgrc file). Where Mercurial packagers aren't setting this, the linked URL in the new abort message can contain instructions for users. In the future, we may want to add more code for finding the system CA store. For example, many Linux distributions have the CA store at well-known locations (such as /etc/ssl/certs/ca-certificates.crt in the case of Ubuntu). This will enable CA loading to "just work" on more Python configurations and will be best for our users since they won't have to change anything after upgrading to a Mercurial with this patch. We may also want to consider distributing a trusted CA store with Mercurial. Although we should think long and hard about that because most systems have a global CA store and Mercurial should almost certainly use the same store used by everything else on the system.
Augie Fackler - - Load All Authors

File last commit:

r27434:11150176 default
r29411:e1778b9c default
Show More
changegroups.txt
157 lines | 6.1 KiB | text/plain | TextLexer
/ mercurial / help / internals / changegroups.txt
History | Annotation | Raw |Copy content |Copy permalink
Changegroups
============
Changegroups are representations of repository revlog data, specifically
the changelog, manifest, and filelogs.
There are 3 versions of changegroups: ``1``, ``2``, and ``3``. From a
high-level, versions ``1`` and ``2`` are almost exactly the same, with
the only difference being a header on entries in the changeset
segment. Version ``3`` adds support for exchanging treemanifests and
includes revlog flags in the delta header.
Changegroups consists of 3 logical segments::
+---------------------------------+
| | | |
| changeset | manifest | filelogs |
| | | |
+---------------------------------+
The principle building block of each segment is a *chunk*. A *chunk*
is a framed piece of data::
+---------------------------------------+
| | |
| length | data |
| (32 bits) | <length> bytes |
| | |
+---------------------------------------+
Each chunk starts with a 32-bit big-endian signed integer indicating
the length of the raw data that follows.
There is a special case chunk that has 0 length (``0x00000000``). We
call this an *empty chunk*.
Delta Groups
------------
A *delta group* expresses the content of a revlog as a series of deltas,
or patches against previous revisions.
Delta groups consist of 0 or more *chunks* followed by the *empty chunk*
to signal the end of the delta group::
+------------------------------------------------------------------------+
| | | | | |
| chunk0 length | chunk0 data | chunk1 length | chunk1 data | 0x0 |
| (32 bits) | (various) | (32 bits) | (various) | (32 bits) |
| | | | | |
+------------------------------------------------------------+-----------+
Each *chunk*'s data consists of the following::
+-----------------------------------------+
| | | |
| delta header | mdiff header | delta |
| (various) | (12 bytes) | (various) |
| | | |
+-----------------------------------------+
The *length* field is the byte length of the remaining 3 logical pieces
of data. The *delta* is a diff from an existing entry in the changelog.
The *delta header* is different between versions ``1``, ``2``, and
``3`` of the changegroup format.
Version 1::
+------------------------------------------------------+
| | | | |
| node | p1 node | p2 node | link node |
| (20 bytes) | (20 bytes) | (20 bytes) | (20 bytes) |
| | | | |
+------------------------------------------------------+
Version 2::
+------------------------------------------------------------------+
| | | | | |
| node | p1 node | p2 node | base node | link node |
| (20 bytes) | (20 bytes) | (20 bytes) | (20 bytes) | (20 bytes) |
| | | | | |
+------------------------------------------------------------------+
Version 3::
+------------------------------------------------------------------------------+
| | | | | | |
| node | p1 node | p2 node | base node | link node | flags |
| (20 bytes) | (20 bytes) | (20 bytes) | (20 bytes) | (20 bytes) | (2 bytes) |
| | | | | | |
+------------------------------------------------------------------------------+
The *mdiff header* consists of 3 32-bit big-endian signed integers
describing offsets at which to apply the following delta content::
+-------------------------------------+
| | | |
| offset | old length | new length |
| (32 bits) | (32 bits) | (32 bits) |
| | | |
+-------------------------------------+
In version 1, the delta is always applied against the previous node from
the changegroup or the first parent if this is the first entry in the
changegroup.
In version 2, the delta base node is encoded in the entry in the
changegroup. This allows the delta to be expressed against any parent,
which can result in smaller deltas and more efficient encoding of data.
Changeset Segment
-----------------
The *changeset segment* consists of a single *delta group* holding
changelog data. It is followed by an *empty chunk* to denote the
boundary to the *manifests segment*.
Manifest Segment
----------------
The *manifest segment* consists of a single *delta group* holding
manifest data. It is followed by an *empty chunk* to denote the boundary
to the *filelogs segment*.
Filelogs Segment
----------------
The *filelogs* segment consists of multiple sub-segments, each
corresponding to an individual file whose data is being described::
+--------------------------------------+
| | | | |
| filelog0 | filelog1 | filelog2 | ... |
| | | | |
+--------------------------------------+
In version ``3`` of the changegroup format, filelogs may include
directory logs when treemanifests are in use. directory logs are
identified by having a trailing '/' on their filename (see below).
The final filelog sub-segment is followed by an *empty chunk* to denote
the end of the segment and the overall changegroup.
Each filelog sub-segment consists of the following::
+------------------------------------------+
| | | |
| filename size | filename | delta group |
| (32 bits) | (various) | (various) |
| | | |
+------------------------------------------+
That is, a *chunk* consisting of the filename (not terminated or padded)
followed by N chunks constituting the *delta group* for this file.