Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: GnuPG: gcrypt

[PATCH] Add ability to save/load an md5 checkpoint file

 

 

GnuPG gcrypt RSS feed   Index | Next | Previous | View Threaded


ben.guthro at virtualcomputer

Nov 30, 2011, 1:59 PM

Post #1 of 11 (833 views)
Permalink
[PATCH] Add ability to save/load an md5 checkpoint file

For large encryption streams - it can be convenient to write a checkpoint file,
to be able to be able to resume later.

This implements save/load of md5 checkpoints

Signed-off-by: Ben Guthro <ben.guthro [at] virtualcomputer>

diff --git a/cipher/md.c b/cipher/md.c
index 5ae9aee..7f3115f 100644
--- a/cipher/md.c
+++ b/cipher/md.c
@@ -1315,6 +1315,46 @@ gcry_md_is_enabled (gcry_md_hd_t a, int algo)
return value;
}

+int
+gcry_save_md5_checkpoint(FILE *f, gcry_md_hd_t *hd)
+{
+ GcryDigestEntry *entry;
+ int n;
+
+ n = (*hd)->ctx->actual_handle_size - sizeof (struct gcry_md_context);
+ if (fwrite(*hd, n, 1, f) != 1)
+ return (-1);
+ entry = (*hd)->ctx->list;
+ if (fwrite(entry->context.c, entry->digest->contextsize, 1, f) != 1)
+ return (-1);
+
+ return (0);
+}
+
+int
+gcry_load_md5_checkpoint(FILE *f, gcry_md_hd_t *hd)
+{
+ GcryDigestEntry *entry;
+ void *ctx;
+ int n;
+
+ gcry_md_open(hd, GCRY_MD_MD5, 0);
+ /* see comment above in md_open() for description of layout */
+ ctx = (*hd)->ctx;
+ n = (*hd)->ctx->actual_handle_size - sizeof (struct gcry_md_context);
+ if (fread(*hd, n, 1, f) != 1)
+ goto fail;
+ (*hd)->ctx = ctx;
+ entry = (*hd)->ctx->list;
+ if (fread(entry->context.c, entry->digest->contextsize, 1, f) != 1)
+ goto fail;
+
+ return (0);
+fail:
+ gcry_md_close(*hd);
+ return (-1);
+}
+

/* Run the selftests for digest algorithm ALGO with optional reporting
function REPORT. */
diff --git a/src/gcrypt.h.in b/src/gcrypt.h.in
index b34ff08..565b5d3 100644
--- a/src/gcrypt.h.in
+++ b/src/gcrypt.h.in
@@ -22,6 +22,7 @@
#ifndef _GCRYPT_H
#define _GCRYPT_H

+#include <stdio.h>
#include <stdlib.h>
#include <stdarg.h>
#include <string.h>
@@ -1444,6 +1445,8 @@ int gcry_is_secure (const void *a) _GCRY_GCC_ATTR_PURE;
/* Return true if Libgcrypt is in FIPS mode. */
#define gcry_fips_mode_active() !!gcry_control (GCRYCTL_FIPS_MODE_P, 0)

+int gcry_save_md5_checkpoint(FILE *f, gcry_md_hd_t *hd);
+int gcry_load_md5_checkpoint(FILE *f, gcry_md_hd_t *hd);

#if 0 /* (Keep Emacsens' auto-indent happy.) */
{
diff --git a/src/libgcrypt.def b/src/libgcrypt.def
index 9bf0167..93a3ba1 100644
--- a/src/libgcrypt.def
+++ b/src/libgcrypt.def
@@ -211,3 +211,6 @@ EXPORTS
gcry_pk_get_param @193

gcry_kdf_derive @194
+
+ gcry_save_md5_checkpoint @195
+ gcry_load_md5_checkpoint @196
diff --git a/src/libgcrypt.vers b/src/libgcrypt.vers
index dcb3749..7f32a7d 100644
--- a/src/libgcrypt.vers
+++ b/src/libgcrypt.vers
@@ -88,6 +88,8 @@ GCRYPT_1.6 {
gcry_mpi_subm; gcry_mpi_swap; gcry_mpi_test_bit;
gcry_mpi_lshift;

+ gcry_save_md5_checkpoint; gcry_load_md5_checkpoint;
+
local:
*;

diff --git a/src/visibility.c b/src/visibility.c
index 2d3edbc..3ec73c3 100644
--- a/src/visibility.c
+++ b/src/visibility.c
@@ -1144,3 +1144,15 @@ gcry_is_secure (const void *a)
{
return _gcry_is_secure (a);
}
+
+int
+gcry_save_md5_checkpoint(FILE *f, gcry_md_hd_t *hd)
+{
+ _gcry_save_md5_checkpoint(f, hd);
+}
+
+int
+gcry_load_md5_checkpoint(FILE *f, gcry_md_hd_t *hd)
+{
+ _gcry_load_md5_checkpoint(f, hd);
+}
diff --git a/src/visibility.h b/src/visibility.h
index 4606a20..dc7ec77 100644
--- a/src/visibility.h
+++ b/src/visibility.h
@@ -185,6 +185,8 @@
#define gcry_mpi_swap _gcry_mpi_swap
#define gcry_mpi_test_bit _gcry_mpi_test_bit

+#define gcry_save_md5_checkpoint _gcry_save_md5_checkpoint
+#define gcry_load_md5_checkpoint _gcry_load_md5_checkpoint

/* Include the main header here so that public symbols are mapped to
the internal underscored ones. */
@@ -390,7 +392,8 @@ gcry_err_code_t gcry_md_get (gcry_md_hd_t hd, int algo,
#undef gcry_mpi_subm
#undef gcry_mpi_swap
#undef gcry_mpi_test_bit
-
+#undef gcry_save_md5_checkpoint
+#undef gcry_load_md5_checkpoint

/* Now mark all symbols. */

@@ -557,7 +560,8 @@ MARK_VISIBLE (gcry_mpi_subm)
MARK_VISIBLE (gcry_mpi_swap)
MARK_VISIBLE (gcry_mpi_test_bit)

-
+MARK_VISIBLE (gcry_save_md5_checkpoint)
+MARK_VISIBLE (gcry_load_md5_checkpoint)

#undef MARK_VISIBLE
#endif /*_GCRY_INCLUDED_BY_VISIBILITY_C*/

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


wk at gnupg

Dec 1, 2011, 4:28 AM

Post #2 of 11 (793 views)
Permalink
Re: [PATCH] Add ability to save/load an md5 checkpoint file [In reply to]

On Wed, 30 Nov 2011 22:59, ben.guthro [at] virtualcomputer said:
> For large encryption streams - it can be convenient to write a checkpoint file,
> to be able to be able to resume later.

I can image that is is usable. However, your code does not fit into the
Libgcrypt architecture: It is only for an old and for most purposes
broken algorithm, it uses direct write to a file and it is not
architecture neutral. Further we would need copyright assignments to
the FSF.

A better way of doing this is to have a general way of serializing and
exporting/importing the state of a hash algorithm. Given that the state
is an internal property of Libgcrypt, we can't export it because that
would mean to keep that serialized state compatible to all future
versions; this is a too high burden for maintenance. What we can do is
to return the state a long with a version number and allow restoring it
only if the version number matches - that should be okay for this
purpose.

It is a bit of work, though.


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


ben.guthro at virtualcomputer

Dec 1, 2011, 4:49 AM

Post #3 of 11 (789 views)
Permalink
Re: [PATCH] Add ability to save/load an md5 checkpoint file [In reply to]

I figured it was a bit of a long shot that you'd take the patch as-is...but thought it was
useful functionality that might, at least spark a discussion as to the proper way to
implement such a feature that would be acceptable upstream.

As for copyright assignments...doesn't the code fall under the existing copyright in
the file?

On Dec 1, 2011, at 7:28 AM, Werner Koch wrote:

> On Wed, 30 Nov 2011 22:59, ben.guthro [at] virtualcomputer said:
>> For large encryption streams - it can be convenient to write a checkpoint file,
>> to be able to be able to resume later.
>
> I can image that is is usable. However, your code does not fit into the
> Libgcrypt architecture: It is only for an old and for most purposes
> broken algorithm, it uses direct write to a file and it is not
> architecture neutral. Further we would need copyright assignments to
> the FSF.
>
> A better way of doing this is to have a general way of serializing and
> exporting/importing the state of a hash algorithm. Given that the state
> is an internal property of Libgcrypt, we can't export it because that
> would mean to keep that serialized state compatible to all future
> versions; this is a too high burden for maintenance. What we can do is
> to return the state a long with a version number and allow restoring it
> only if the version number matches - that should be okay for this
> purpose.
>
> It is a bit of work, though.
>
>
> Salam-Shalom,
>
> Werner
>
>
> --
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
>


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


wk at gnupg

Dec 1, 2011, 6:59 AM

Post #4 of 11 (799 views)
Permalink
Re: [PATCH] Add ability to save/load an md5 checkpoint file [In reply to]

On Thu, 1 Dec 2011 13:49, ben.guthro [at] virtualcomputer said:

> I figured it was a bit of a long shot that you'd take the patch
> as-is...but thought it was useful functionality that might, at least
> spark a discussion as to the proper way to implement such a feature
> that would be acceptable upstream.

That worked.

> As for copyright assignments...doesn't the code fall under the
> existing copyright in the file?

No. For non-trivial changes the FSF requires a written (i.e. paper)
copyright assignment. If I would add code from you, you would have the
copyright on that parts of the code. Now if for example the FSF wants
to change the license (say from GPL to LGPL) they would have to get your
permission to do that. Now consider there are dozens of authors and
some may not agree or are simply not anymore reachable. Thus copyright
assignments are the way to go.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


ben.guthro at virtualcomputer

Dec 1, 2011, 7:32 AM

Post #5 of 11 (782 views)
Permalink
Re: [PATCH] Add ability to save/load an md5 checkpoint file [In reply to]

Sorry to hear that.

I guess I will not be contributing to this OSS project.

I have contributed to quite a few projects in the pas - both for work, and as a private developer.
All of these works have always fallen under the copyright in the file header.
I have never filled out paperwork, and have no intention to do so in the near future.

Best of luck to you, and Stallman in stifling innovation by way of dead trees.

Feel free to re-imlement this idea, should you see fit, independent of this patch.

/btg

On Dec 1, 2011, at 9:59 AM, Werner Koch wrote:

> On Thu, 1 Dec 2011 13:49, ben.guthro [at] virtualcomputer said:
>
>> I figured it was a bit of a long shot that you'd take the patch
>> as-is...but thought it was useful functionality that might, at least
>> spark a discussion as to the proper way to implement such a feature
>> that would be acceptable upstream.
>
> That worked.
>
>> As for copyright assignments...doesn't the code fall under the
>> existing copyright in the file?
>
> No. For non-trivial changes the FSF requires a written (i.e. paper)
> copyright assignment. If I would add code from you, you would have the
> copyright on that parts of the code. Now if for example the FSF wants
> to change the license (say from GPL to LGPL) they would have to get your
> permission to do that. Now consider there are dozens of authors and
> some may not agree or are simply not anymore reachable. Thus copyright
> assignments are the way to go.
>
>
> Shalom-Salam,
>
> Werner
>
> --
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
>


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


wk at gnupg

Dec 2, 2011, 1:46 AM

Post #6 of 11 (778 views)
Permalink
Re: [PATCH] Add ability to save/load an md5 checkpoint file [In reply to]

On Thu, 1 Dec 2011 16:32, ben.guthro [at] virtualcomputer said:

> Best of luck to you, and Stallman in stifling innovation by way of dead trees.

That is required by the US copyright law. It is not RMS' idea.

BTW, a lot of high profile projects require copyright assignments, for
example X11 or Samba. There are also companies who require that
(e.g. Sun's OpenOffice, Canonical's Ubuntu, Oracls's MySQL, etc.); I
would actually hesitate to sign such company CAs - they don't guarantee
that the assigned code will stay free. In contrast the FSF guarantees
this and give you all the reciprocal rights as possible by US law.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


andre at amorim

Dec 2, 2011, 1:58 AM

Post #7 of 11 (776 views)
Permalink
Re: [PATCH] Add ability to save/load an md5 checkpoint file [In reply to]

open .. payday ?

On 2 December 2011 09:46, Werner Koch <wk [at] gnupg> wrote:
> On Thu,  1 Dec 2011 16:32, ben.guthro [at] virtualcomputer said:
>
>> Best of luck to you, and Stallman in stifling innovation by way of dead trees.
>
> That is required by the US copyright law.  It is not RMS' idea.
>
> BTW, a lot of high profile projects require copyright assignments, for
> example X11 or Samba.  There are also companies who require that
> (e.g. Sun's OpenOffice, Canonical's Ubuntu, Oracls's MySQL, etc.); I
> would actually hesitate to sign such company CAs - they don't guarantee
> that the assigned code will stay free.  In contrast the FSF guarantees
> this and give you all the reciprocal rights as possible by US law.
>
>
> Shalom-Salam,
>
>   Werner
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
>
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel [at] gnupg
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel



--
Gnupg key: 02375205
Fingerprint: F7CD D181 943B 0453 8668  AF16 84E9 7565 0237 5205

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


wk at gnupg

Dec 2, 2011, 12:04 PM

Post #8 of 11 (779 views)
Permalink
Re: [PATCH] Add ability to save/load an md5 checkpoint file [In reply to]

On Fri, 2 Dec 2011 10:58, andre [at] amorim said:
> open .. payday ?

Care to explain?


Salam-Shalom,

Werner


A3: Please.
Q3: Should I avoid top posting on this mailing list?

A2: Because, by reversing the order of a conversation, it leaves the
reader without much context, and makes them read a message in an
unnatural order.
Q2: Why is top posting irritating?

A1: It is the practice of putting your reply to a message before the
quoted message, instead of after the (trimmed) message.
Q1: What is top posting?


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


bradh at frogmouth

Dec 2, 2011, 4:44 PM

Post #9 of 11 (778 views)
Permalink
Re: [PATCH] Add ability to save/load an md5 checkpoint file [In reply to]

On Fri, 2 Dec 2011 08:46:03 PM Werner Koch wrote:
> BTW, a lot of high profile projects require copyright assignments, for
> example X11 or Samba.
I don't know about X11, but Samba doesn't require copyright assignment.
http://www.samba.org/samba/devel/copyright-policy.html

Its a personal choice as to whether you want to go through the pain of the
FSF's process. For some people, its OK; for others, its a barrier to entry.
Personally, I've done it for some FSF projects, but I probably wouldn't do it
again.

Brad

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


andre at amorim

Dec 2, 2011, 9:38 PM

Post #10 of 11 (773 views)
Permalink
Re: [PATCH] Add ability to save/load an md5 checkpoint file [In reply to]

I am very sorry for the cognitive dissonant, to be honest I was so
tired that I slept immediately after writing the email and now even
for myself is hard to get the line of thought again, the unconscious
mind has its own language... but was something about volunteer,
donations, no obligation, business model, dual licence, etc..

Again, apologize.

Andre Amorim

On 2 December 2011 20:04, Werner Koch <wk [at] gnupg> wrote:
> On Fri,  2 Dec 2011 10:58, andre [at] amorim said:
>> open .. payday ?
>
> Care to explain?
>
>
> Salam-Shalom,
>
>   Werner
>
>
> A3: Please.
> Q3: Should I avoid top posting on this mailing list?
>
> A2: Because, by reversing the order of a conversation, it leaves the
>    reader without much context, and makes them read a message in an
>    unnatural order.
> Q2: Why is top posting irritating?
>
> A1: It is the practice of putting your reply to a message before the
>    quoted message, instead of after the (trimmed) message.
> Q1: What is top posting?
>
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>



--
Gnupg key: 02375205
Fingerprint: F7CD D181 943B 0453 8668  AF16 84E9 7565 0237 5205

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


wk at gnupg

Dec 3, 2011, 7:38 AM

Post #11 of 11 (769 views)
Permalink
Re: [PATCH] Add ability to save/load an md5 checkpoint file [In reply to]

On Sat, 3 Dec 2011 01:44, bradh [at] frogmouth said:

> I don't know about X11, but Samba doesn't require copyright assignment.
> http://www.samba.org/samba/devel/copyright-policy.html

Oops. I got that wrong while remembering the latest change in the Samba
policy [1] which is on how to handle work by employees. I was not
anymore able to find anything regarding X11 copyright assignmens; it is
possible that back in these times X11 (not Xfree86) was controlled by
corporations which always require such a thing.

Other examples are Qt (which recently dropped it) and MySQL or MariaSQL.

Copyright assignment are a hot topic these days and there are lots of
pros and cons. The FSF policy is old and has only been slighly revised
over the years. However, this is what we have to use for (core) GNU
projects. One of the goals of the GNU Advisory Committee [2] is to look
at problematic areas in GNU software development requirements and try to
fix them. There is no roadmap, though..


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

GnuPG gcrypt RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.