threads / discuss / 41646

libcurl dependency for implementing RFC3161 timestamps

Subject: libcurl dependency for implementing RFC3161 timestamps

## tl;dr

4 messages between Mar 9, 2016 and Mar 9, 2016.

replies: 3people: 4as markdown or json

Anton Wuerfel· Mar 9, 2016, 11:24 UTC · lore

Hello,

for implementing RFC3161 timestamps in git tag, HTTP POST requests have to be sent via libcurl. We already changed http.c to our needs.

Is there any best-practice how to introduce this libcurl dependency? There are several options:

-As git tag is a builtin part of the main git executable, introduce a libcurl dependency for the main executable (maybe not best-practice).

-Move git tag to a separate git-tag binary and introduce a libcurl dependency to this new submodule.

-Create an own submodule like git-http-timestamp with a libcurl dependency and call it from git tag and from other places where timestamp signatures are needed.

Regards, Phillip Raffeck Anton Wuerfel

Duy Nguyen· Mar 9, 2016, 11:41 UTC · re: Anton Wuerfel · lore

Re: libcurl dependency for implementing RFC3161 timestamps

On Wed, Mar 9, 2016 at 6:24 PM, Anton Wuerfel <anton.wuerfel@fau.de> wrote:

> -As git tag is a builtin part of the main git executable, introduce a
> libcurl dependency for the main executable (maybe not best-practice).

libcurl was part of the main executable and then split out because it increased startup time [1]. I don't know if it's still true nowadays, maybe you should do a simple test before deciding to go that way.

[1] http://article.gmane.org/gmane.comp.version-control.git/123946

-- 
Duy

Randall S. Becker· Mar 9, 2016, 13:04 UTC · re: Duy Nguyen · lore

RE: libcurl dependency for implementing RFC3161 timestamps

On March 9, 2016 6:41 AM, Duy Nguyen wrote:

Show 13 quoted lines

> To: Anton Wuerfel <anton.wuerfel@fau.de>
> Cc: Git Mailing List <git@vger.kernel.org>; i4passt@cs.fau.de;
> phillip.raffeck@fau.de
> Subject: Re: libcurl dependency for implementing RFC3161 timestamps
> 
> On Wed, Mar 9, 2016 at 6:24 PM, Anton Wuerfel <anton.wuerfel@fau.de>
> wrote:
> > -As git tag is a builtin part of the main git executable, introduce a
> > libcurl dependency for the main executable (maybe not best-practice).
> 
> libcurl was part of the main executable and then split out because it
> increased startup time [1]. I don't know if it's still true nowadays, maybe you
> should do a simple test before deciding to go that way.

The NSE NonStop port observed that at 2.7.3 (admittedly old) that libcurl was not used for local operations including status, log, reset, etc., but was needed for push, pull, fetch (a.k.a. network) operations. The libcurl.so is loaded statically at start-up for any components needing the latter operations. Added it for local processing is not going to help performance :(, which is quite bad enough on our platform.

Sincerely, Randall

-- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(211288444200000000) -- In my real life, I talk too much.

Junio C Hamano· Mar 9, 2016, 18:53 UTC · re: Anton Wuerfel · lore

Re: libcurl dependency for implementing RFC3161 timestamps

"Anton Wuerfel" <anton.wuerfel@fau.de> writes:

Show 12 quoted lines

> Is there any best-practice how to introduce this libcurl dependency? There
> are several options:
>
> -As git tag is a builtin part of the main git executable, introduce a
> libcurl dependency for the main executable (maybe not best-practice).
>
> -Move git tag to a separate git-tag binary and introduce a libcurl
> dependency to this new submodule.
>
> -Create an own submodule like git-http-timestamp with a libcurl dependency
> and call it from git tag and from other places where timestamp signatures
> are needed.

If this were to become part of the official Git distribution, I think the last one would be the most realistic approach.

In fact, just like the way that Git does not care how GPG implements its crypto, manages the chain of trust, and any other details, I think the best way to integrate it would be to write your own RFC3161 program that can be invoked just like we invoke GPG, and drive it via an interface like we drive GPG via gpg-interface.[ch], since Git shouldn't even care where your timestamp is coming from and over what transport.