Re: [PATCH] setup.c: set workdir when gitdir is not default
On Wed, Sep 3, 2014 at 6:42 PM, Max Kirillov m...@max630.net wrote:
When gitfile is used, git sets GIT_DIR environment variable for
subsequent commands, and that commands start working in mode GIT_DIR
set, workdir current, which is incorrect for the case when git runs
from subdirectory of repository. This can be observed at least for
running aliases - git fails with message internal error: work tree has
already been set
Fix by setting GIT_WORK_TREE environment also.
Add test which demonstrates problem with alias.
Signed-off-by: Max Kirillov m...@max630.net
---
setup.c| 4 +++-
t/t0002-gitfile.sh | 7 +++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/setup.c b/setup.c
index 0a22f8b..bcf4e31 100644
--- a/setup.c
+++ b/setup.c
@@ -508,8 +508,10 @@ static const char *setup_discovered_git_dir(const char
*gitdir,
/* #0, #1, #5, #8, #9, #12, #13 */
set_git_work_tree(.);
- if (strcmp(gitdir, DEFAULT_GIT_DIR_ENVIRONMENT))
+ if (strcmp(gitdir, DEFAULT_GIT_DIR_ENVIRONMENT)) {
set_git_dir(gitdir);
+ setenv(GIT_WORK_TREE_ENVIRONMENT, get_git_work_tree(), 1);
+ }
inside_git_dir = 0;
inside_work_tree = 1;
if (offset == len)
diff --git a/t/t0002-gitfile.sh b/t/t0002-gitfile.sh
index 37e9396..428cfdc 100755
--- a/t/t0002-gitfile.sh
+++ b/t/t0002-gitfile.sh
@@ -99,4 +99,11 @@ test_expect_success 'check rev-list' '
test $SHA = $(git rev-list HEAD)
'
+test_expect_success 'check alias call from subdirectory' '
+ git config alias.testalias rev-parse HEAD
Perhaps use test_config here?
+ mkdir -p subdir
+ cd subdir
+ git testalias
If a new test is added following this one, it will be run from within
'subdir', which might come as a surprise as the author of the new
test. Wrapping the 'cd' and following code in a subshell is a good way
to avoid the problem.
mkdir -p subdir
(
cd subdir
git testalias
)
+'
+
test_done
--
2.0.1.1697.g73c6810
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 10/21] send-pack: rename new_refs to need_pack_data
The variable counts how many non-deleting command is being sent, but
is only checked with 0-ness to decide if we need to send the pack
data.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
send-pack.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/send-pack.c b/send-pack.c
index c1c64ee..590eb0a 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -220,7 +220,7 @@ int send_pack(struct send_pack_args *args,
struct strbuf req_buf = STRBUF_INIT;
struct strbuf cap_buf = STRBUF_INIT;
struct ref *ref;
- int new_refs;
+ int need_pack_data = 0;
int allow_deleting_refs = 0;
int status_report = 0;
int use_sideband = 0;
@@ -276,13 +276,12 @@ int send_pack(struct send_pack_args *args,
/*
* Finally, tell the other end!
*/
- new_refs = 0;
for (ref = remote_refs; ref; ref = ref-next) {
if (!ref_update_to_be_sent(ref, args))
continue;
if (!ref-deletion)
- new_refs++;
+ need_pack_data = 1;
if (args-dry_run) {
ref-status = REF_STATUS_OK;
@@ -327,7 +326,7 @@ int send_pack(struct send_pack_args *args,
in = demux.out;
}
- if (new_refs cmds_sent) {
+ if (need_pack_data cmds_sent) {
if (pack_objects(out, remote_refs, extra_have, args) 0) {
for (ref = remote_refs; ref; ref = ref-next)
ref-status = REF_STATUS_NONE;
--
2.1.0-399-g1364b4d
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 11/21] send-pack: refactor inspecting and resetting status and sending commands
The main loop over remote_refs list inspects the ref status
to see if we need to generate pack data (i.e. a delete-only push
does not need to send any additional data), resets it to expecting
the status report state, and formats the actual update commands
to be sent.
Split the former two out of the main loop, as it will become
conditional in later steps.
Besides, we should have code that does real thing here, before the
Finally, tell the other end! part ;-)
Signed-off-by: Junio C Hamano gits...@pobox.com
---
send-pack.c | 49 ++---
1 file changed, 30 insertions(+), 19 deletions(-)
diff --git a/send-pack.c b/send-pack.c
index 590eb0a..f3262f2 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -274,7 +274,8 @@ int send_pack(struct send_pack_args *args,
advertise_shallow_grafts_buf(req_buf);
/*
-* Finally, tell the other end!
+* Clear the status for each ref and see if we need to send
+* the pack data.
*/
for (ref = remote_refs; ref; ref = ref-next) {
if (!ref_update_to_be_sent(ref, args))
@@ -283,25 +284,35 @@ int send_pack(struct send_pack_args *args,
if (!ref-deletion)
need_pack_data = 1;
- if (args-dry_run) {
+ if (args-dry_run || !status_report)
ref-status = REF_STATUS_OK;
- } else {
- char *old_hex = sha1_to_hex(ref-old_sha1);
- char *new_hex = sha1_to_hex(ref-new_sha1);
-
- if (!cmds_sent)
- packet_buf_write(req_buf,
-%s %s %s%c%s,
-old_hex, new_hex, ref-name, 0,
-cap_buf.buf);
- else
- packet_buf_write(req_buf, %s %s %s,
-old_hex, new_hex, ref-name);
- ref-status = status_report ?
- REF_STATUS_EXPECTING_REPORT :
- REF_STATUS_OK;
- cmds_sent++;
- }
+ else
+ ref-status = REF_STATUS_EXPECTING_REPORT;
+ }
+
+ /*
+* Finally, tell the other end!
+*/
+ for (ref = remote_refs; ref; ref = ref-next) {
+ char *old_hex, *new_hex;
+
+ if (args-dry_run)
+ continue;
+
+ if (!ref_update_to_be_sent(ref, args))
+ continue;
+
+ old_hex = sha1_to_hex(ref-old_sha1);
+ new_hex = sha1_to_hex(ref-new_sha1);
+ if (!cmds_sent)
+ packet_buf_write(req_buf,
+%s %s %s%c%s,
+old_hex, new_hex, ref-name, 0,
+cap_buf.buf);
+ else
+ packet_buf_write(req_buf, %s %s %s,
+old_hex, new_hex, ref-name);
+ cmds_sent++;
}
if (args-stateless_rpc) {
--
2.1.0-399-g1364b4d
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 09/21] receive-pack: factor out capability string generation
Similar to the previous one for send-pack, make it easier and
cleaner to add to capability advertisement.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/receive-pack.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 341bb46..9c39fb7 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -137,15 +137,21 @@ static void show_ref(const char *path, const unsigned
char *sha1)
if (ref_is_hidden(path))
return;
- if (sent_capabilities)
+ if (sent_capabilities) {
packet_write(1, %s %s\n, sha1_to_hex(sha1), path);
- else
- packet_write(1, %s %s%c%s%s agent=%s\n,
-sha1_to_hex(sha1), path, 0,
- report-status delete-refs side-band-64k quiet,
-prefer_ofs_delta ? ofs-delta : ,
-git_user_agent_sanitized());
- sent_capabilities = 1;
+ } else {
+ struct strbuf cap = STRBUF_INIT;
+
+ strbuf_addstr(cap,
+ report-status delete-refs side-band-64k quiet);
+ if (prefer_ofs_delta)
+ strbuf_addstr(cap, ofs-delta);
+ strbuf_addf(cap, agent=%s, git_user_agent_sanitized());
+ packet_write(1, %s %s%c%s\n,
+sha1_to_hex(sha1), path, 0, cap.buf);
+ strbuf_release(cap);
+ sent_capabilities = 1;
+ }
}
static int show_ref_cb(const char *path, const unsigned char *sha1, int flag,
void *unused)
--
2.1.0-399-g1364b4d
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 14/21] gpg-interface: move parse_signature() to where it should be
Our signed-tag objects set the standard format used by Git to store
GPG-signed payload (i.e. the payload followed by its detached
signature), and it made sense to have a helper to find the boundary
between the payload and its signature in tag.c back then.
Newer code added later to parse other kinds of objects that learned
to use the same format to store GPG-signed payload (e.g. signed
commits), however, kept using the helper from the same location.
Move it to gpg-interface; the helper is no longer about signed tag,
but it is how our code and data interact with GPG.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
gpg-interface.c | 21 +
gpg-interface.h | 1 +
tag.c | 20
tag.h | 1 -
4 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/gpg-interface.c b/gpg-interface.c
index 3c9624c..0dd11ea 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -7,6 +7,9 @@
static char *configured_signing_key;
static const char *gpg_program = gpg;
+#define PGP_SIGNATURE -BEGIN PGP SIGNATURE-
+#define PGP_MESSAGE -BEGIN PGP MESSAGE-
+
void signature_check_clear(struct signature_check *sigc)
{
free(sigc-payload);
@@ -57,6 +60,24 @@ void parse_gpg_output(struct signature_check *sigc)
}
}
+/*
+ * Look at GPG signed content (e.g. a signed tag object), whose
+ * payload is followed by a detached signature on it. Return the
+ * offset where the embedded detached signature begins, or the end of
+ * the data when there is no such signature.
+ */
+size_t parse_signature(const char *buf, unsigned long size)
+{
+ char *eol;
+ size_t len = 0;
+ while (len size !starts_with(buf + len, PGP_SIGNATURE)
+ !starts_with(buf + len, PGP_MESSAGE)) {
+ eol = memchr(buf + len, '\n', size - len);
+ len += eol ? eol - (buf + len) + 1 : size - len;
+ }
+ return len;
+}
+
void set_signing_key(const char *key)
{
free(configured_signing_key);
diff --git a/gpg-interface.h b/gpg-interface.h
index 8d677cc..93c76c2 100644
--- a/gpg-interface.h
+++ b/gpg-interface.h
@@ -20,6 +20,7 @@ struct signature_check {
};
extern void signature_check_clear(struct signature_check *sigc);
+extern size_t parse_signature(const char *buf, unsigned long size);
extern void parse_gpg_output(struct signature_check *);
extern int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const
char *signing_key);
diff --git a/tag.c b/tag.c
index 82d841b..5b0ac62 100644
--- a/tag.c
+++ b/tag.c
@@ -4,9 +4,6 @@
#include tree.h
#include blob.h
-#define PGP_SIGNATURE -BEGIN PGP SIGNATURE-
-#define PGP_MESSAGE -BEGIN PGP MESSAGE-
-
const char *tag_type = tag;
struct object *deref_tag(struct object *o, const char *warn, int warnlen)
@@ -143,20 +140,3 @@ int parse_tag(struct tag *item)
free(data);
return ret;
}
-
-/*
- * Look at a signed tag object, and return the offset where
- * the embedded detached signature begins, or the end of the
- * data when there is no such signature.
- */
-size_t parse_signature(const char *buf, unsigned long size)
-{
- char *eol;
- size_t len = 0;
- while (len size !starts_with(buf + len, PGP_SIGNATURE)
- !starts_with(buf + len, PGP_MESSAGE)) {
- eol = memchr(buf + len, '\n', size - len);
- len += eol ? eol - (buf + len) + 1 : size - len;
- }
- return len;
-}
diff --git a/tag.h b/tag.h
index bc8a1e4..f4580ae 100644
--- a/tag.h
+++ b/tag.h
@@ -17,6 +17,5 @@ extern int parse_tag_buffer(struct tag *item, const void
*data, unsigned long si
extern int parse_tag(struct tag *item);
extern struct object *deref_tag(struct object *, const char *, int);
extern struct object *deref_tag_noverify(struct object *);
-extern size_t parse_signature(const char *buf, unsigned long size);
#endif /* TAG_H */
--
2.1.0-399-g1364b4d
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 07/21] send-pack: always send capabilities
We tried to avoid sending one extra byte, NUL and nothing behind it
to signal there is no protocol capabilities being sent, on the first
command packet on the wire, but it just made the code look ugly.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
send-pack.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/send-pack.c b/send-pack.c
index f3c5ebe..2fa6c34 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -281,8 +281,7 @@ int send_pack(struct send_pack_args *args,
char *new_hex = sha1_to_hex(ref-new_sha1);
int quiet = quiet_supported (args-quiet ||
!args-progress);
- if (!cmds_sent (status_report || use_sideband ||
- quiet || agent_supported)) {
+ if (!cmds_sent)
packet_buf_write(req_buf,
%s %s %s%c%s%s%s%s%s,
old_hex, new_hex, ref-name, 0,
@@ -292,7 +291,6 @@ int send_pack(struct send_pack_args *args,
agent_supported ? agent= :
,
agent_supported ?
git_user_agent_sanitized() :
);
- }
else
packet_buf_write(req_buf, %s %s %s,
old_hex, new_hex, ref-name);
--
2.1.0-399-g1364b4d
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 19/21] signed push: remove duplicated protocol info
With the interim protocol, we used to send the update commands even though we already send a signed copy of the same information when push certificate is in use. Update the send-pack/receive-pack pair not to do so. The notable thing on the receive-pack side is that it makes sure that there is no command sent over the traditional protocol packet outside the push certificate. Otherwise a pusher can claim to be pushing one set of ref updates in the signed certificate while issuing commands to update unrelated refs, and such an update will evade later audits. Finally, start documenting the protocol. Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/technical/pack-protocol.txt | 33 ++- Documentation/technical/protocol-capabilities.txt | 12 +++-- builtin/receive-pack.c| 30 +++-- send-pack.c | 2 +- 4 files changed, 71 insertions(+), 6 deletions(-) diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index a845d51..4a5c2e8 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -465,7 +465,7 @@ contain all the objects that the server will need to complete the new references. - update-request= *shallow command-list [pack-file] + update-request= *shallow ( command-list | push-cert ) [pack-file] shallow = PKT-LINE(shallow SP obj-id) @@ -481,12 +481,25 @@ references. old-id= obj-id new-id= obj-id + push-cert = PKT-LINE(push-cert NUL capability-list LF) + PKT-LINE(certificate version 0.1 LF) + PKT-LINE(pusher SP ident LF) + PKT-LINE(LF) + *PKT-LINE(command LF) + *PKT-LINE(gpg-signature-lines LF) + PKT-LINE(push-cert-end LF) + pack-file = PACK 28*(OCTET) If the receiving end does not support delete-refs, the sending end MUST NOT ask for delete command. +If the receiving end does not support push-cert, the sending end +MUST NOT send a push-cert command. When a push-cert command is +sent, command-list MUST NOT be sent; the commands recorded in the +push certificate is used instead. + The pack-file MUST NOT be sent if the only command used is 'delete'. A pack-file MUST be sent if either create or update command is used, @@ -501,6 +514,24 @@ was being processed (the obj-id is still the same as the old-id), and it will run any update hooks to make sure that the update is acceptable. If all of that is fine, the server will then update the references. +Push Certificate + + +A push certificate begins with a set of header lines. After the +header and an empty line, the protocol commands follow, one per +line. + +Currently, the following header fields are defined: + +`pusher` ident:: + Identify the GPG key in Human Readable Name email@address + format. + +The GPG signature lines are a detached signature for the contents +recorded in the push certificate before the signature block begins. +The detached signature is used to certify that the commands were +given by the pusher, who must be the signer. + Report Status - diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index e174343..a478cc4 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -18,8 +18,8 @@ was sent. Server MUST NOT ignore capabilities that client requested and server advertised. As a consequence of these rules, server MUST NOT advertise capabilities it does not understand. -The 'report-status', 'delete-refs', and 'quiet' capabilities are sent and -recognized by the receive-pack (push to server) process. +The 'report-status', 'delete-refs', 'quiet', and 'push-cert' capabilities +are sent and recognized by the receive-pack (push to server) process. The 'ofs-delta' and 'side-band-64k' capabilities are sent and recognized by both upload-pack and receive-pack protocols. The 'agent' capability @@ -250,3 +250,11 @@ allow-tip-sha1-in-want If the upload-pack server advertises this capability, fetch-pack may send want lines with SHA-1s that exist at the server but are not advertised by upload-pack. + +push-cert +- + +The receive-pack server that advertises this capability is willing +to accept a signed push certificate. A send-pack client MUST NOT +send a push-cert packet unless the receive-pack server advertises +this capability. diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c index bfd078c..2d93c87 100644 --- a/builtin/receive-pack.c +++ b/builtin/receive-pack.c @@ -899,7 +899,7 @@ static void execute_commands(struct command *commands, the reported refs above); }
[PATCH v3 12/21] send-pack: clarify that cmds_sent is a boolean
We use it to make sure that the feature request is sent only once on
the very first request packet (ignoring the shallow line, which
was an unfortunate mistake we cannot retroactively fix with existing
receive-pack already deployed in the field) and we set it to true
with cmds_sent++, not because we care about the actual number of
updates sent but because it is merely an old idiomatic way.
Set it explicitly to one to clarify that the code that uses this
variable only cares about its zero-ness.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
send-pack.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/send-pack.c b/send-pack.c
index f3262f2..05926d2 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -304,15 +304,16 @@ int send_pack(struct send_pack_args *args,
old_hex = sha1_to_hex(ref-old_sha1);
new_hex = sha1_to_hex(ref-new_sha1);
- if (!cmds_sent)
+ if (!cmds_sent) {
packet_buf_write(req_buf,
%s %s %s%c%s,
old_hex, new_hex, ref-name, 0,
cap_buf.buf);
- else
+ cmds_sent = 1;
+ } else {
packet_buf_write(req_buf, %s %s %s,
old_hex, new_hex, ref-name);
- cmds_sent++;
+ }
}
if (args-stateless_rpc) {
--
2.1.0-399-g1364b4d
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 08/21] send-pack: factor out capability string generation
A run of 'var ? var : ' fed to a long printf string in a deeply
nested block was hard to read. Move it outside the loop and format
it into a strbuf.
As an added bonus, the trick to add agent=agent-name by using
two conditionals is replaced by a more readable version.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
send-pack.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/send-pack.c b/send-pack.c
index 2fa6c34..c1c64ee 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -218,6 +218,7 @@ int send_pack(struct send_pack_args *args,
int in = fd[0];
int out = fd[1];
struct strbuf req_buf = STRBUF_INIT;
+ struct strbuf cap_buf = STRBUF_INIT;
struct ref *ref;
int new_refs;
int allow_deleting_refs = 0;
@@ -251,6 +252,15 @@ int send_pack(struct send_pack_args *args,
return 0;
}
+ if (status_report)
+ strbuf_addstr(cap_buf, report-status);
+ if (use_sideband)
+ strbuf_addstr(cap_buf, side-band-64k);
+ if (quiet_supported (args-quiet || !args-progress))
+ strbuf_addstr(cap_buf, quiet);
+ if (agent_supported)
+ strbuf_addf(cap_buf, agent=%s, git_user_agent_sanitized());
+
/*
* NEEDSWORK: why is delete-refs so specific to send-pack
* machinery that set_ref_status_for_push() cannot set this
@@ -279,18 +289,12 @@ int send_pack(struct send_pack_args *args,
} else {
char *old_hex = sha1_to_hex(ref-old_sha1);
char *new_hex = sha1_to_hex(ref-new_sha1);
- int quiet = quiet_supported (args-quiet ||
!args-progress);
if (!cmds_sent)
packet_buf_write(req_buf,
-%s %s %s%c%s%s%s%s%s,
+%s %s %s%c%s,
old_hex, new_hex, ref-name, 0,
-status_report ?
report-status : ,
-use_sideband ?
side-band-64k : ,
-quiet ? quiet : ,
-agent_supported ? agent= :
,
-agent_supported ?
git_user_agent_sanitized() :
- );
+cap_buf.buf);
else
packet_buf_write(req_buf, %s %s %s,
old_hex, new_hex, ref-name);
@@ -311,6 +315,7 @@ int send_pack(struct send_pack_args *args,
packet_flush(out);
}
strbuf_release(req_buf);
+ strbuf_release(cap_buf);
if (use_sideband cmds_sent) {
memset(demux, 0, sizeof(demux));
--
2.1.0-399-g1364b4d
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 13/21] gpg-interface: move parse_gpg_output() to where it should be
Earlier, ffb6d7d5 (Move commit GPG signature verification to
commit.c, 2013-03-31) moved this helper that used to be in pretty.c
(i.e. the output code path) to commit.c for better reusability.
It was a good first step in the right direction, but still suffers a
myopic view that commits will be the only thing we would ever want
to sign---we would actually want to be able to reuse it even wider.
The function interprets what GPG said; gpg-interface is obviously a
better place. Move it there.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
commit.c| 36
gpg-interface.c | 36
gpg-interface.h | 17 -
3 files changed, 48 insertions(+), 41 deletions(-)
diff --git a/commit.c b/commit.c
index ae7f2b1..01cdad2 100644
--- a/commit.c
+++ b/commit.c
@@ -1220,42 +1220,6 @@ free_return:
free(buf);
}
-static struct {
- char result;
- const char *check;
-} sigcheck_gpg_status[] = {
- { 'G', \n[GNUPG:] GOODSIG },
- { 'B', \n[GNUPG:] BADSIG },
- { 'U', \n[GNUPG:] TRUST_NEVER },
- { 'U', \n[GNUPG:] TRUST_UNDEFINED },
-};
-
-static void parse_gpg_output(struct signature_check *sigc)
-{
- const char *buf = sigc-gpg_status;
- int i;
-
- /* Iterate over all search strings */
- for (i = 0; i ARRAY_SIZE(sigcheck_gpg_status); i++) {
- const char *found, *next;
-
- if (!skip_prefix(buf, sigcheck_gpg_status[i].check + 1,
found)) {
- found = strstr(buf, sigcheck_gpg_status[i].check);
- if (!found)
- continue;
- found += strlen(sigcheck_gpg_status[i].check);
- }
- sigc-result = sigcheck_gpg_status[i].result;
- /* The trust messages are not followed by key/signer
information */
- if (sigc-result != 'U') {
- sigc-key = xmemdupz(found, 16);
- found += 17;
- next = strchrnul(found, '\n');
- sigc-signer = xmemdupz(found, next - found);
- }
- }
-}
-
void check_commit_signature(const struct commit* commit, struct
signature_check *sigc)
{
struct strbuf payload = STRBUF_INIT;
diff --git a/gpg-interface.c b/gpg-interface.c
index ff07012..3c9624c 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -21,6 +21,42 @@ void signature_check_clear(struct signature_check *sigc)
sigc-key = NULL;
}
+static struct {
+ char result;
+ const char *check;
+} sigcheck_gpg_status[] = {
+ { 'G', \n[GNUPG:] GOODSIG },
+ { 'B', \n[GNUPG:] BADSIG },
+ { 'U', \n[GNUPG:] TRUST_NEVER },
+ { 'U', \n[GNUPG:] TRUST_UNDEFINED },
+};
+
+void parse_gpg_output(struct signature_check *sigc)
+{
+ const char *buf = sigc-gpg_status;
+ int i;
+
+ /* Iterate over all search strings */
+ for (i = 0; i ARRAY_SIZE(sigcheck_gpg_status); i++) {
+ const char *found, *next;
+
+ if (!skip_prefix(buf, sigcheck_gpg_status[i].check + 1,
found)) {
+ found = strstr(buf, sigcheck_gpg_status[i].check);
+ if (!found)
+ continue;
+ found += strlen(sigcheck_gpg_status[i].check);
+ }
+ sigc-result = sigcheck_gpg_status[i].result;
+ /* The trust messages are not followed by key/signer
information */
+ if (sigc-result != 'U') {
+ sigc-key = xmemdupz(found, 16);
+ found += 17;
+ next = strchrnul(found, '\n');
+ sigc-signer = xmemdupz(found, next - found);
+ }
+ }
+}
+
void set_signing_key(const char *key)
{
free(configured_signing_key);
diff --git a/gpg-interface.h b/gpg-interface.h
index 37c23da..8d677cc 100644
--- a/gpg-interface.h
+++ b/gpg-interface.h
@@ -5,16 +5,23 @@ struct signature_check {
char *payload;
char *gpg_output;
char *gpg_status;
- char result; /* 0 (not checked),
- * N (checked but no further result),
- * U (untrusted good),
- * G (good)
- * B (bad) */
+
+ /*
+* possible result:
+* 0 (not checked)
+* N (checked but no further result)
+* U (untrusted good)
+* G (good)
+* B (bad)
+*/
+ char result;
char *signer;
char *key;
};
extern void signature_check_clear(struct signature_check *sigc);
+extern void parse_gpg_output(struct signature_check *);
+
extern int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const
char *signing_key);
extern int verify_signed_buffer(const char *payload, size_t payload_size,
const char *signature, size_t
[PATCH v3 17/21] receive-pack: GPG-validate push certificates
Reusing the GPG signature check helpers we already have, verify
the signature in receive-pack and give the results to the hooks
via GIT_PUSH_CERT_{SIGNER,KEY,STATUS} environment variables.
Policy decisions, such as accepting or rejecting a good signature by
a key that is not fully trusted, is left to the hook and kept
outside of the core.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-receive-pack.txt | 27 ++-
builtin/receive-pack.c | 31 +++
t/t5534-push-signed.sh | 18 --
3 files changed, 69 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-receive-pack.txt
b/Documentation/git-receive-pack.txt
index 6c458af..60151a6 100644
--- a/Documentation/git-receive-pack.txt
+++ b/Documentation/git-receive-pack.txt
@@ -56,7 +56,21 @@ sha1-old and sha1-new should be valid objects in the
repository.
When accepting a signed push (see linkgit:git-push[1]), the signed
push certificate is stored in a blob and an environment variable
`GIT_PUSH_CERT` can be consulted for its object name. See the
-description of `post-receive` hook for an example.
+description of `post-receive` hook for an example. In addition, the
+certificate is verified using GPG and the result is exported with
+the following environment variables:
+
+GIT_PUSH_CERT_SIGNER::
+ The name and the e-mail address of the owner of the key that
+ signed the push certificate.
+
+GIT_PUSH_CERT_KEY::
+ The GPG key ID of the key that signed the push certificate.
+
+GIT_PUSH_CERT_STATUS::
+ The status of GPG verification of the push certificate,
+ using the same mnemonic as used in `%G?` format of `git log`
+ family of commands (see linkgit:git-log[1]).
This hook is called before any refname is updated and before any
fast-forward checks are performed.
@@ -106,13 +120,14 @@ the update. Refs that were created will have sha1-old
equal to
0\{40}, otherwise sha1-old and sha1-new should be valid objects in
the repository.
-The `GIT_PUSH_CERT` environment variable can be inspected, just as
+The `GIT_PUSH_CERT*` environment variables can be inspected, just as
in `pre-receive` hook, after accepting a signed push.
Using this hook, it is easy to generate mails describing the updates
to the repository. This example script sends one mail message per
ref listing the commits pushed to the repository, and logs the push
-certificates of signed pushes to a file:
+certificates of signed pushes with good signatures to a logger
+service:
#!/bin/sh
# mail out commit update information.
@@ -129,9 +144,11 @@ certificates of signed pushes to a file:
mail -s Changes to ref $ref commit-list@mydomain
done
# log signed push certificate, if any
- if test -n ${GIT_PUSH_CERT-}
+ if test -n ${GIT_PUSH_CERT-} test ${GIT_PUSH_CERT_STATUS} = G
then
- git cat-file blob ${GIT_PUSH_CERT} /var/log/push-log
+ (
+ git cat-file blob ${GIT_PUSH_CERT}
+ ) | mail -s push from $GIT_PUSH_CERT_SIGNER push-log@mydomain
fi
exit 0
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 4335309..bfd078c 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -15,6 +15,8 @@
#include connected.h
#include argv-array.h
#include version.h
+#include tag.h
+#include gpg-interface.h
static const char receive_pack_usage[] = git receive-pack git-dir;
@@ -49,6 +51,7 @@ static const char *alt_shallow_file;
static int accept_push_cert = 1;
static struct strbuf push_cert = STRBUF_INIT;
static unsigned char push_cert_sha1[20];
+static struct signature_check sigcheck;
static enum deny_action parse_deny_action(const char *var, const char *value)
{
@@ -277,12 +280,40 @@ static void prepare_push_cert_sha1(struct child_process
*proc)
return;
if (!already_done) {
+ struct strbuf gpg_output = STRBUF_INIT;
+ struct strbuf gpg_status = STRBUF_INIT;
+ int bogs /* beginning_of_gpg_sig */;
+
already_done = 1;
if (write_sha1_file(push_cert.buf, push_cert.len, blob,
push_cert_sha1))
hashclr(push_cert_sha1);
+
+ memset(sigcheck, '\0', sizeof(sigcheck));
+ sigcheck.result = 'N';
+
+ bogs = parse_signature(push_cert.buf, push_cert.len);
+ if (verify_signed_buffer(push_cert.buf, bogs,
+push_cert.buf + bogs, push_cert.len -
bogs,
+gpg_output, gpg_status) 0) {
+ ; /* error running gpg */
+ } else {
+ sigcheck.payload = push_cert.buf;
+ sigcheck.gpg_output = gpg_output.buf;
+ sigcheck.gpg_status = gpg_status.buf;
+
[PATCH v3 20/21] signed push: add pushee header to push certificate
Record the URL of the intended recipient for a push (after
anonymizing it if it has authentication material) on a new pushee
URL header. Because the networking configuration (SSH-tunnels,
proxies, etc.) on the pushing user's side varies, the receiving
repository may not know the single canonical URL all the pushing
users would refer it as (besides, many sites allow pushing over
ssh://host/path and https://host/path protocols to the same
repository but with different local part of the path). So this
value may not be reliably used for replay-attack prevention
purposes, but this will still serve as a human readable hint to
identify the repository the certificate refers to.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/technical/pack-protocol.txt | 6 ++
send-pack.c | 5 +
send-pack.h | 1 +
transport.c | 1 +
4 files changed, 13 insertions(+)
diff --git a/Documentation/technical/pack-protocol.txt
b/Documentation/technical/pack-protocol.txt
index 4a5c2e8..7b543dc 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -484,6 +484,7 @@ references.
push-cert = PKT-LINE(push-cert NUL capability-list LF)
PKT-LINE(certificate version 0.1 LF)
PKT-LINE(pusher SP ident LF)
+ PKT-LINE(pushee SP url LF)
PKT-LINE(LF)
*PKT-LINE(command LF)
*PKT-LINE(gpg-signature-lines LF)
@@ -527,6 +528,11 @@ Currently, the following header fields are defined:
Identify the GPG key in Human Readable Name email@address
format.
+`pushee` url::
+ The repository URL (anonymized, if the URL contains
+ authentication material) the user who ran `git push`
+ intended to push into.
+
The GPG signature lines are a detached signature for the contents
recorded in the push certificate before the signature block begins.
The detached signature is used to certify that the commands were
diff --git a/send-pack.c b/send-pack.c
index 61f321d..642ebc8 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -240,6 +240,11 @@ static int generate_push_cert(struct strbuf *req_buf,
datestamp(stamp, sizeof(stamp));
strbuf_addf(cert, certificate version 0.1\n);
strbuf_addf(cert, pusher %s %s\n, signing_key, stamp);
+ if (args-url *args-url) {
+ char *anon_url = transport_anonymize_url(args-url);
+ strbuf_addf(cert, pushee %s\n, anon_url);
+ free(anon_url);
+ }
strbuf_addstr(cert, \n);
for (ref = remote_refs; ref; ref = ref-next) {
diff --git a/send-pack.h b/send-pack.h
index 3555d8e..5635457 100644
--- a/send-pack.h
+++ b/send-pack.h
@@ -2,6 +2,7 @@
#define SEND_PACK_H
struct send_pack_args {
+ const char *url;
unsigned verbose:1,
quiet:1,
porcelain:1,
diff --git a/transport.c b/transport.c
index 07fdf86..1df1375 100644
--- a/transport.c
+++ b/transport.c
@@ -827,6 +827,7 @@ static int git_transport_push(struct transport *transport,
struct ref *remote_re
args.dry_run = !!(flags TRANSPORT_PUSH_DRY_RUN);
args.porcelain = !!(flags TRANSPORT_PUSH_PORCELAIN);
args.push_cert = !!(flags TRANSPORT_PUSH_CERT);
+ args.url = transport-url;
ret = send_pack(args, data-fd, data-conn, remote_refs,
data-extra_have);
--
2.1.0-399-g1364b4d
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 15/21] pack-protocol doc: typofix for PKT-LINE
Everywhere else we use PKT-LINE to denote the pkt-line formatted data, but shallow/deepen messages are described with PKT_LINE(). Fix them. Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/technical/pack-protocol.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index 18dea8d..a845d51 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -212,9 +212,9 @@ out of what the server said it could do with the first 'want' line. want-list = first-want *additional-want - shallow-line = PKT_LINE(shallow SP obj-id) + shallow-line = PKT-LINE(shallow SP obj-id) - depth-request = PKT_LINE(deepen SP depth) + depth-request = PKT-LINE(deepen SP depth) first-want= PKT-LINE(want SP obj-id SP capability-list LF) additional-want = PKT-LINE(want SP obj-id LF) -- 2.1.0-399-g1364b4d -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 21/21] signed push: fortify against replay attacks
In order to prevent a valid push certificate for pushing into an
repository from getting replayed to push to an unrelated one, send a
nonce string from the receive-pack process and have the signer
include it in the push certificate. The original nonce is exported
as GIT_PUSH_CERT_NONCE for the hooks to examine and match against
the value on the nonce header in the certificate to notice a
replay.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-receive-pack.txt| 8
Documentation/technical/pack-protocol.txt | 6 ++
Documentation/technical/protocol-capabilities.txt | 7 ---
builtin/receive-pack.c| 21 +++--
send-pack.c | 19 +++
t/t5534-push-signed.sh| 17 +++--
6 files changed, 63 insertions(+), 15 deletions(-)
diff --git a/Documentation/git-receive-pack.txt
b/Documentation/git-receive-pack.txt
index 60151a6..983b24e 100644
--- a/Documentation/git-receive-pack.txt
+++ b/Documentation/git-receive-pack.txt
@@ -72,6 +72,13 @@ GIT_PUSH_CERT_STATUS::
using the same mnemonic as used in `%G?` format of `git log`
family of commands (see linkgit:git-log[1]).
+GIT_PUSH_CERT_NONCE::
+ The nonce string the process asked the signer to include
+ in the push certificate. If this does not match the value
+ recorded on the nonce header in the push certificate, it
+ may indicate that the certificate is a valid one that is
+ being replayed from a separate git push session.
+
This hook is called before any refname is updated and before any
fast-forward checks are performed.
@@ -147,6 +154,7 @@ service:
if test -n ${GIT_PUSH_CERT-} test ${GIT_PUSH_CERT_STATUS} = G
then
(
+ echo expected nonce is ${GIT_PUSH_NONCE}
git cat-file blob ${GIT_PUSH_CERT}
) | mail -s push from $GIT_PUSH_CERT_SIGNER push-log@mydomain
fi
diff --git a/Documentation/technical/pack-protocol.txt
b/Documentation/technical/pack-protocol.txt
index 7b543dc..dda1206 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -485,6 +485,7 @@ references.
PKT-LINE(certificate version 0.1 LF)
PKT-LINE(pusher SP ident LF)
PKT-LINE(pushee SP url LF)
+ PKT-LINE(nonce SP nonce LF)
PKT-LINE(LF)
*PKT-LINE(command LF)
*PKT-LINE(gpg-signature-lines LF)
@@ -533,6 +534,11 @@ Currently, the following header fields are defined:
authentication material) the user who ran `git push`
intended to push into.
+`nonce` nonce::
+ The 'nonce' string the receiving repository asked the
+ pushing user to include in the certificate, to prevent
+ replay attacks.
+
The GPG signature lines are a detached signature for the contents
recorded in the push certificate before the signature block begins.
The detached signature is used to certify that the commands were
diff --git a/Documentation/technical/protocol-capabilities.txt
b/Documentation/technical/protocol-capabilities.txt
index a478cc4..0c92dee 100644
--- a/Documentation/technical/protocol-capabilities.txt
+++ b/Documentation/technical/protocol-capabilities.txt
@@ -251,10 +251,11 @@ If the upload-pack server advertises this capability,
fetch-pack may
send want lines with SHA-1s that exist at the server but are not
advertised by upload-pack.
-push-cert
--
+push-cert=nonce
+-
The receive-pack server that advertises this capability is willing
-to accept a signed push certificate. A send-pack client MUST NOT
+to accept a signed push certificate, and asks the nonce to be
+included in the push certificate. A send-pack client MUST NOT
send a push-cert packet unless the receive-pack server advertises
this capability.
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 2d93c87..9abfc94 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -52,6 +52,7 @@ static int accept_push_cert = 1;
static struct strbuf push_cert = STRBUF_INIT;
static unsigned char push_cert_sha1[20];
static struct signature_check sigcheck;
+static const char *push_cert_nonce;
static enum deny_action parse_deny_action(const char *var, const char *value)
{
@@ -157,8 +158,8 @@ static void show_ref(const char *path, const unsigned char
*sha1)
report-status delete-refs side-band-64k quiet);
if (prefer_ofs_delta)
strbuf_addstr(cap, ofs-delta);
- if (accept_push_cert)
- strbuf_addstr(cap, push-cert);
+ if (accept_push_cert push_cert_nonce)
+ strbuf_addf(cap, push-cert=%s,
[PATCH v3 06/21] send-pack: refactor decision to send update per ref
A new helper function ref_update_to_be_sent() decides for each ref
if the update is to be sent based on the status previously set by
set_ref_status_for_push() and also if this is a mirrored push.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
send-pack.c | 36 +---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/send-pack.c b/send-pack.c
index 7428ae6..f3c5ebe 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -190,6 +190,26 @@ static void advertise_shallow_grafts_buf(struct strbuf *sb)
for_each_commit_graft(advertise_shallow_grafts_cb, sb);
}
+static int ref_update_to_be_sent(const struct ref *ref, const struct
send_pack_args *args)
+{
+ if (!ref-peer_ref !args-send_mirror)
+ return 0;
+
+ /* Check for statuses set by set_ref_status_for_push() */
+ switch (ref-status) {
+ case REF_STATUS_REJECT_NONFASTFORWARD:
+ case REF_STATUS_REJECT_ALREADY_EXISTS:
+ case REF_STATUS_REJECT_FETCH_FIRST:
+ case REF_STATUS_REJECT_NEEDS_FORCE:
+ case REF_STATUS_REJECT_STALE:
+ case REF_STATUS_REJECT_NODELETE:
+ case REF_STATUS_UPTODATE:
+ return 0;
+ default:
+ return 1;
+ }
+}
+
int send_pack(struct send_pack_args *args,
int fd[], struct child_process *conn,
struct ref *remote_refs,
@@ -248,23 +268,9 @@ int send_pack(struct send_pack_args *args,
*/
new_refs = 0;
for (ref = remote_refs; ref; ref = ref-next) {
- if (!ref-peer_ref !args-send_mirror)
+ if (!ref_update_to_be_sent(ref, args))
continue;
- /* Check for statuses set by set_ref_status_for_push() */
- switch (ref-status) {
- case REF_STATUS_REJECT_NONFASTFORWARD:
- case REF_STATUS_REJECT_ALREADY_EXISTS:
- case REF_STATUS_REJECT_FETCH_FIRST:
- case REF_STATUS_REJECT_NEEDS_FORCE:
- case REF_STATUS_REJECT_STALE:
- case REF_STATUS_REJECT_NODELETE:
- case REF_STATUS_UPTODATE:
- continue;
- default:
- ; /* do nothing */
- }
-
if (!ref-deletion)
new_refs++;
--
2.1.0-399-g1364b4d
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Configurable filename for what is now .gitignore
I see, tnx for the pointer.
Would inclusion of this patch be viable option then?
Patch below, it is possible to look at it here to:
Patch:
https://github.com/teonsystems/git/commit/27449825ff4d7bb3eecb5a3e32692aaf1ab1a026
Branch:
https://github.com/teonsystems/git/commits/feature/configurable-gitignore-filename
commit 27449825ff4d7bb3eecb5a3e32692aaf1ab1a026
Author: Bostjan Skufca bost...@a2o.si
Date: Thu Sep 4 20:20:30 2014 +
.gitignore: make '.gitignore' filename configurable
When using git with detached work tree and .git directory,
it is currently impossible to use multiple git repositories
with the same workdir, as .gitignore is always parsed.
This feature keeps the original '.gitignore' file as default
at almost no performance penalty, and enables reconfiguring
git to use alternate filename when obtaining per-dir exclusion
patterns.
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c55c22a..1c63b13 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -507,6 +507,17 @@ be delta compressed, but larger binary media
files won't be.
+
Common unit suffixes of 'k', 'm', or 'g' are supported.
+core.excludesperdirfilename::
+ By default, Git checks for presence of .gitignore files to read
+ exclude patterns from. This option enables the customization of
+ per-dir exclude patterns filename that is by default called
+ '.gitignore', to arbitrary filename.
++
+This setting is not implicitly distributed when transferring
+changes between repository clones. In order to achieve identical
+behaviour in all repository clones, each repository clone must
+set this option to the same value.
+
core.excludesfile::
In addition to '.gitignore' (per-directory) and
'.git/info/exclude', Git looks into this file for patterns
diff --git a/cache.h b/cache.h
index 4d5b76c..ff952b4 100644
--- a/cache.h
+++ b/cache.h
@@ -392,6 +392,7 @@ static inline enum object_type
object_type(unsigned int mode)
#define NO_REPLACE_OBJECTS_ENVIRONMENT GIT_NO_REPLACE_OBJECTS
#define GITATTRIBUTES_FILE .gitattributes
#define INFOATTRIBUTES_FILE info/attributes
+#define GITIGNORE_FILE .gitignore
#define ATTRIBUTE_MACRO_PREFIX [attr]
#define GIT_NOTES_REF_ENVIRONMENT GIT_NOTES_REF
#define GIT_NOTES_DEFAULT_REF refs/notes/commits
@@ -1423,6 +1424,7 @@ extern int check_pager_config(const char *cmd);
extern const char *editor_program;
extern const char *askpass_program;
+extern const char *excludes_per_dir_filename;
extern const char *excludes_file;
/* base85 */
diff --git a/config.c b/config.c
index a191328..da80556 100644
--- a/config.c
+++ b/config.c
@@ -847,6 +847,9 @@ static int git_default_core_config(const char
*var, const char *value)
if (!strcmp(var, core.askpass))
return git_config_string(askpass_program, var, value);
+ if (!strcmp(var, core.excludesperdirfilename))
+ return git_config_string(excludes_per_dir_filename, var, value);
+
if (!strcmp(var, core.excludesfile))
return git_config_pathname(excludes_file, var, value);
diff --git a/dir.c b/dir.c
index bd274a7..8b429c3 100644
--- a/dir.c
+++ b/dir.c
@@ -1624,7 +1624,12 @@ void setup_standard_excludes(struct dir_struct *dir)
const char *path;
char *xdg_path;
- dir-exclude_per_dir = .gitignore;
+ if (excludes_per_dir_filename) {
+ dir-exclude_per_dir = excludes_per_dir_filename;
+ } else {
+ dir-exclude_per_dir = GITIGNORE_FILE;
+ }
+
path = git_path(info/exclude);
if (!excludes_file) {
home_config_paths(NULL, xdg_path, ignore);
diff --git a/environment.c b/environment.c
index 565f652..0d48ef9 100644
--- a/environment.c
+++ b/environment.c
@@ -43,6 +43,7 @@ const char *pager_program;
int pager_use_color = 1;
const char *editor_program;
const char *askpass_program;
+const char *excludes_per_dir_filename;
const char *excludes_file;
enum auto_crlf auto_crlf = AUTO_CRLF_FALSE;
int check_replace_refs = 1;
diff --git a/t/t7515-status-changed-gitignore-filename.sh
b/t/t7515-status-changed-gitignore-filename.sh
new file mode 100755
index 000..ed7de42
--- /dev/null
+++ b/t/t7515-status-changed-gitignore-filename.sh
@@ -0,0 +1,72 @@
+#!/bin/sh
+
+test_description='status with changed default .gitignore filename'
+. ./test-lib.sh
+
+
+#
+# Check if only single file is in 'untracked' state: file2
+# file1 is excluded by ignore pattern in .gitignore (default)
+#
+test_expect_success 'status with default .gitignore filename' '
+ mkdir repo-default
+ (cd repo-default git init
+ echo /file1 .gitignore
+ git add .gitignore
+ touch file1
+ touch file2
+ COUNT_UNTRACKED=`git status | grep -P ^\t | grep -P -v ^\tnew
file: | grep -c .`
+ if [ $COUNT_UNTRACKED == 1 ]; then
+ true
+ else
+ false
+ fi
+ )
+'
+
+
+#
+# Check if only single file is in 'untracked' state: file2
+# file1 is excluded by ignore pattern in .gitexclude (modified
default ignore filename)
+#
+test_expect_success 'status with .gitignore filename reconfigured to
.gitexclude' '
+ mkdir
Re: [PATCH v3 20/21] signed push: add pushee header to push certificate
On Thu, Sep 4, 2014 at 1:04 PM, Junio C Hamano gits...@pobox.com wrote: Record the URL of the intended recipient for a push (after anonymizing it if it has authentication material) on a new pushee URL header. Because the networking configuration (SSH-tunnels, proxies, etc.) on the pushing user's side varies, the receiving repository may not know the single canonical URL all the pushing users would refer it as (besides, many sites allow pushing over ssh://host/path and https://host/path protocols to the same repository but with different local part of the path). So this value may not be reliably used for replay-attack prevention purposes, but this will still serve as a human readable hint to identify the repository the certificate refers to. Well, a push cert validator could require the pushee use specific URL(s) known to it. The server operator knows their URL space and could just demand that users use ssh://host/path and https://host/path and nothing fancy like aliases in ~/.ssh/config. But I think you are right to punt on that and let the cert validator hook written by the server operator to decide if pushee should be verified. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git format-patch --in-reply-to allows header injection. Intended?
Hi, I just wanted to ask if the --in-reply-to flag of git format-patch is supposed to write the given string unmodified into the email or whether it ought to perform some check against header injection. For example, if you pass --in-reply-to=msgid\nTo: ot...@example.com (notice lack of trailing ``), then the generated email will actually contain a To: ot...@example.com header. (Depending on your shell you might also use --in-reply-to=`cat` to get the above working more easily.) Is this known and working as intended, or undesired? Thanks! Niklas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] setup.c: set workdir when gitdir is not default
When gitfile is used, git sets GIT_DIR environment variable for
subsequent commands, and that commands start working in mode GIT_DIR
set, workdir current, which is incorrect for the case when git runs
from subdirectory of repository. This can be observed at least for
running aliases - git fails with message internal error: work tree has
already been set
Fix by setting GIT_WORK_TREE environment also.
Add test which demonstrates problem with alias.
Signed-off-by: Max Kirillov m...@max630.net
---
setup.c| 4 +++-
t/t0002-gitfile.sh | 9 +
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/setup.c b/setup.c
index 0a22f8b..bcf4e31 100644
--- a/setup.c
+++ b/setup.c
@@ -508,8 +508,10 @@ static const char *setup_discovered_git_dir(const char
*gitdir,
/* #0, #1, #5, #8, #9, #12, #13 */
set_git_work_tree(.);
- if (strcmp(gitdir, DEFAULT_GIT_DIR_ENVIRONMENT))
+ if (strcmp(gitdir, DEFAULT_GIT_DIR_ENVIRONMENT)) {
set_git_dir(gitdir);
+ setenv(GIT_WORK_TREE_ENVIRONMENT, get_git_work_tree(), 1);
+ }
inside_git_dir = 0;
inside_work_tree = 1;
if (offset == len)
diff --git a/t/t0002-gitfile.sh b/t/t0002-gitfile.sh
index 37e9396..64d59c3 100755
--- a/t/t0002-gitfile.sh
+++ b/t/t0002-gitfile.sh
@@ -99,4 +99,13 @@ test_expect_success 'check rev-list' '
test $SHA = $(git rev-list HEAD)
'
+test_expect_success 'check alias call from subdirectory' '
+ test_config alias.testalias rev-parse HEAD
+ mkdir -p subdir
+ (
+ cd subdir
+ git testalias
+ )
+'
+
test_done
--
2.0.1.1697.g73c6810
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git format-patch --in-reply-to allows header injection. Intended?
Niklas Hambüchen m...@nh2.me writes: For example, if you pass --in-reply-to=msgid\nTo: ot...@example.com (notice lack of trailing ``), then the generated email will actually contain a To: ot...@example.com header. While I do not think of a reason to specify such a string to the in-reply-to option (I'd rather edit the output in the editor if I wanted to do anything fancy [*1*]), I do not think there is a reason why you want to add a code to forbid such use, either. [Footnote] *1* For that matter, --in-reply-to option itself is superfluous. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2014 retrospective (Git Config API Improvements)
Tanay Abhra tanay...@gmail.com writes: GSoC Experience --- ... Conclusion -- So a great summer comes to an end. Hopefully I would still be part of Git's community and will continue working on it to improve it. I like to thank my mentors for being patient with me and helping me whenever I got confused. Hope you all have a great day. :) Happy to see a great write-up. Looking forward to seeing your further involvement in the community. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git format-patch --in-reply-to allows header injection. Intended?
On 04/09/14 23:36, Junio C Hamano wrote: While I do not think of a reason to specify such a string to the in-reply-to option (I'd rather edit the output in the editor if I wanted to do anything fancy [*1*]), I do not think there is a reason why you want to add a code to forbid such use, either. My question was to find out whether I can pass untrusted user input to --in-reply-to and expect that no header beyond In-Reply-To and References is modified, but your answer makes clear that I cannot. A possible alternative might have been that git verifies that the input to --in-reply-to matches the format specified RFC2822 (section 3.6.4.). Thanks! -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Interactive staging not functioning properly?
Sorry, I just realized that when the hunks are across file boundaries, it won't go back to it. I think this is a bit misleading, it would be great to see it go back to the ACTUAL previous hunk, regardless of which file it came from. On Thu, Sep 4, 2014 at 4:54 PM, Robert Dailey rcdailey.li...@gmail.com wrote: I run the following: $ git add -p I skip the first hunk by typing n. At the next hunk, I try k and K. In both cases, it shows me the same hunk I'm on again and says No previous hunk. Is this intended behavior? I expect to be taken back to the previous hunk that I did not stage. Running Git 2.1.0 on msysgit Windows. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv2 1/2] am: add gitk patch format
Hi Junio, On Fri, Sep 5, 2014 at 5:21 AM, Junio C Hamano gits...@pobox.com wrote: Chris Packham judge.pack...@gmail.com writes: Another thing that I've since realised is that this 'gitk' format is also what you've get from git show or git log -p. So this is actually allowing (for better or worse) things like 'git show $sha1 | git am --patch-format=gitk'[*1*]. That may mean that we should call the format something else (pretty perhaps?) and note that this is what gitk, git show and some incantations of git log generate. I would not call it pretty, because --pretty is merely a short-hand to --pretty=some format name. The output format indents the log message text by four spaces for human reading to make it stand out from the patch text, and not meant for machine consumption. Fair enough. I doubt that a patchset that does not update mailinfo and mailsplit to extract information and to undo the indentation could be a right solution. I've read this sentence a couple of times and I can't understand it. I get that you are against adding yet more special cases to 'git am' to handle patches that weren't generated by 'git format-patch'. Are you saying that this won't go in or that the solution should be implemented differently. am itself should not be mucking with the input files. At the very least we need to drop the first line and replace Author with From. Which would still leave the commit message indented. Something like the following allows the patch to be applied sed -e '1d' -e 's/^Author:/From:/' patch.patch | git am But it'd be nice if am could do that for me to save my fingers some work. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 18/18] signed push: final protocol update
Shawn Pearce spea...@spearce.org writes: As you know, the stateless HTTP thing doesn't allow the nonce on the server to be carried from the initial ref advertisement into the final receive-pack. We would either need to write the nonce to disk and load it back up later (ick), or use some sort of stateless nonce. A stateless nonce could look like: nonce = HMAC_SHA1( SHA1(site+path) + '.' + now, site_key ) where site_key is a private key known to the server. It doesn't have to be per-repo. Doing the above naively will force you to check 600 HMAC if your slack is for 10 minutes. You could just instead use nonce = now '-' HMAC_SHA1(path + '.' + now, site_key) and the validation side can make sure the same site_key was used, and also now readable from the plaintext part is fresh enough, with a single HMAC. I may be missing something, but with this, we can always validate that nonce is what the repository issued (whether stateless is used or not). The hook script can decide if now is recent enough or not without bothering receive-pack at all. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git format-patch --in-reply-to allows header injection. Intended?
Niklas Hambüchen m...@nh2.me writes: On 04/09/14 23:36, Junio C Hamano wrote: While I do not think of a reason to specify such a string to the in-reply-to option (I'd rather edit the output in the editor if I wanted to do anything fancy [*1*]), I do not think there is a reason why you want to add a code to forbid such use, either. My question was to find out whether I can pass untrusted user input to ... Ah, in general, anybody who passes unvetted user input to any Git Porcelain deserves what s/he gets, so perhaps you would want to at least make sure that the input is a single line, or something. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Sep 2014, #01; Tue, 2)
On Thu, Sep 4, 2014 at 11:51 PM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: On Wed, Sep 3, 2014 at 5:06 AM, Junio C Hamano gits...@pobox.com wrote: * nd/multiple-work-trees (2014-07-29) 39 commits Reroll posted, but haven't picked up yet. How would this interact with rr/transaction series which is pretty much all about the refs? Haven't checked out that topic yet. But ref changes in multiple-work-trees are to make sure ref path construction goess through git_path(), and some cleaning up after strbuf_git_path() is introduced. So basically textual conflicts only. Up to the point that is queued on 'pu', the other topic(s) still keep the assumption that all refs are files in $GIT_DIR/refs/, and I think I managed the textual conflicts correctly in 'pu' before. But starting from $gmane/255476 the assumption gradually gets lifted and eventually we may have refs and reflogs expressed in a different backend, without these files that represent the refs at all. I am not yet sure how this I have $GIR_DIR/ but that is not a real one but borrows most of the stuff from elsewhere meshes with that new world. The refs/* path conversion should stay with the current filesystem backend. How to share new backends in multiple worktrees is another interesting problem. But I should stop saying any more until I read this backend-struct-db topic. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Sep 2014, #01; Tue, 2)
On Fri, Sep 5, 2014 at 12:14 AM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Duy Nguyen pclo...@gmail.com writes:
On Wed, Sep 3, 2014 at 5:06 AM, Junio C Hamano gits...@pobox.com wrote:
* nd/multiple-work-trees (2014-07-29) 39 commits
Reroll posted, but haven't picked up yet. How would this interact
with rr/transaction series which is pretty much all about the refs?
Haven't checked out that topic yet. But ref changes in
multiple-work-trees are to make sure ref path construction goess
through git_path(), and some cleaning up after strbuf_git_path() is
introduced. So basically textual conflicts only.
Up to the point that is queued on 'pu', the other topic(s) still
keep the assumption that all refs are files in $GIT_DIR/refs/, and I
think I managed the textual conflicts correctly in 'pu' before.
One point that caused unnecessary conflict resolution was that the
transaction series lacked let's use strbuf to hold paths. This
had two immediate side effects, i.e. instead of returning upon
errors, jump to the end with 'goto done/fail' for necessary
clean-up and get rid of git_snpath and use strbuf_git_path, both
of which are good general clean-ups, even if they weren't related to
the multiple worktrees feature, that conflicted with the transaction
series when getting merged.
You can see the interactions by checking
$ git show 'pu^{/^Merge branch .nd/multi}' refs.c
Perhaps these three changes, without the addition of the multiple
worktree feature, should come first as a general clean-up on top of
which both topics can be built?
If that makes your life easier, sure. Changes up until (and including)
c88c438 (setup.c: convert is_git_directory() to use strbuf -
2014-08-30) could be considered cleanups. After that commit, refs.c is
not touched. Will look at your conflict resultion later..
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv2 1/2] am: add gitk patch format
(added back git ml because I accidentally dropped the Cc when replying to Junio). On Fri, Sep 5, 2014 at 10:57 AM, Junio C Hamano gits...@pobox.com wrote: I doubt that a patchset that does not update mailinfo and mailsplit to extract information and to undo the indentation could be a right solution. I've read this sentence a couple of times and I can't understand it. am uses mailsplit on the input file to separate it into one or more input files, each of which represents a single change. On each of them, it uses mailinfo to extract the meta information (e.g. authorship), log message and the patch into separate files. Except when --patch-format=hg|stgit is specified (or detected). In these cases mailsplit is avoided. It does not make any sense for a support for a new input format that does not teach mailinfo how to handle that format. Transforming it into a pseudo e-mail format is not the way to go. If that approach were acceptable, that format conversion filter can be run completely outside am in the first place, no? So teaching git mailinfo to do s/^// (either when asked to or using some heuristic) would be a better approach? I also think we should accept Author: as an acceptable fallback if From: is not present. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 18/18] signed push: final protocol update
On Thu, Sep 4, 2014 at 4:57 PM, Junio C Hamano gits...@pobox.com wrote: Shawn Pearce spea...@spearce.org writes: As you know, the stateless HTTP thing doesn't allow the nonce on the server to be carried from the initial ref advertisement into the final receive-pack. We would either need to write the nonce to disk and load it back up later (ick), or use some sort of stateless nonce. A stateless nonce could look like: nonce = HMAC_SHA1( SHA1(site+path) + '.' + now, site_key ) where site_key is a private key known to the server. It doesn't have to be per-repo. Doing the above naively will force you to check 600 HMAC if your slack is for 10 minutes. You could just instead use nonce = now '-' HMAC_SHA1(path + '.' + now, site_key) and the validation side can make sure the same site_key was used, and also now readable from the plaintext part is fresh enough, with a single HMAC. Argh. Yes, thank you. This is what I meant but did not write. :( I may be missing something, but with this, we can always validate that nonce is what the repository issued (whether stateless is used or not). The hook script can decide if now is recent enough or not without bothering receive-pack at all. Correct. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 22/32] checkout: support checking out into a new working directory
On Tue, Sep 02, 2014 at 10:51:47AM -0400, Marc Branchaud wrote: MULTIPLE WORKING TREES -- A git repository can support multiple working trees, allowing you to check out more than one branch at a time. With `git checkout --to` a new working tree is associated with the repository. This new working tree is called a linked working tree as opposed to the main working tree prepared by git init or git clone. A repository has one main working tree (if it's not a bare repository) and zero or more linked working trees. Each linked working tree has a private sub-directory in the repository's $GIT_DIR/worktrees directory. The private sub-directory's name is usually the base name of the linked working tree's path, possibly appended with a number to make it unique. For example, when `$GIT_DIR=/path/main/.git` the command `git checkout --to /path/other/test-next next` creates the linked working tree in `/path/other/test-next` and also creates a `$GIT_DIR/worktrees/test-next` directory (or `$GIT_DIR/worktrees/test-next1` if `test-next` is already taken). As a user, this leaves me with one other question -- what happens when I'm done with the test-next working tree and want to delete/rename it? Is that cleaned up automatically, or do I need to register that I'm getting rid of/renaming it? (Another use case is if I put the working tree on removable media for some reason.) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-svn.txt: Remove mentions of repack options
Git no longer seems to use these flags or their associated config keys; when they are present, git-svn outputs a message indicating that they are being ignored. Signed-off-by: Lawrence Velázquez v...@larryv.me --- Documentation/git-svn.txt | 15 --- 1 file changed, 15 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 44c970c..14036cf 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -608,21 +608,6 @@ config key: svn.authorsfile Make 'git svn' less verbose. Specify a second time to make it even less verbose. ---repack[=n]:: ---repack-flags=flags:: - These should help keep disk usage sane for large fetches with - many revisions. -+ ---repack takes an optional argument for the number of revisions -to fetch before repacking. This defaults to repacking every -1000 commits fetched if no argument is specified. -+ ---repack-flags are passed directly to 'git repack'. -+ -[verse] -config key: svn.repack -config key: svn.repackflags - -m:: --merge:: -sstrategy:: -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
