Re: [PATCH 1/2] introduce "banned function" list

2018-07-20 Thread Theodore Y. Ts'o
On Thu, Jul 19, 2018 at 09:08:08PM -0400, Jeff King wrote: > Ditto for sprintf, where you should _always_ be using at least xsnprintf > (or some better tool, depending on the situation). And for strncpy, > strlcpy (or again, some better tool) is strictly an improvement. Nitpick: this may be true

Re: de-alphabetizing the documentation

2018-07-06 Thread Theodore Y. Ts'o
On Fri, Jul 06, 2018 at 04:21:47PM -0700, frede...@ofb.net wrote: > I don't think that it's really important to find a "best" ordering for > commands or glossary terms; it's more a matter of finding someone who > is willing to take responsibility for choosing a reasonable ordering. > Presumably

Re: GDPR compliance best practices?

2018-06-13 Thread Theodore Y. Ts'o
On Tue, Jun 12, 2018 at 09:12:19PM +0200, Peter Backes wrote: > This incorrect claim is completely inverting the logic of Art. 17. > > The logic is clarly that if ANY of lit (a) to (f) is satisfied, the > data must be deleted. > > It is not necessary for ALL of them to be satisfied. > > In

Re: GDPR compliance best practices?

2018-06-09 Thread Theodore Y. Ts'o
On Sat, Jun 09, 2018 at 11:50:32PM +0100, Philip Oakley wrote: > I just want to remind folks that Gmane disappeared as a regular list because > of a legal challenge, the SCO v IBM Unix court case keeps rumbling on, so > clarifying the legal case for: > a) holding the 'personal git meta data', and

Re: GDPR compliance best practices?

2018-06-08 Thread Theodore Y. Ts'o
On Fri, Jun 08, 2018 at 08:26:57AM +0200, Peter Backes wrote: > > If you run a website where the world can access a repository, you are > responsible for obeying the GDPR with respect to that repository. If > you receive a request to be forgotten, you have to make sure you stop > publishing

Re: GDPR compliance best practices?

2018-06-07 Thread Theodore Y. Ts'o
On Fri, Jun 08, 2018 at 01:21:29AM +0200, Peter Backes wrote: > On Thu, Jun 07, 2018 at 03:38:49PM -0700, David Lang wrote: > > > Again: The GDPR certainly allows you to keep a proof of copyright > > > privately if you have it. However, it does not allow you to keep > > > publishing it if someone

Re: GDPR compliance best practices?

2018-06-04 Thread Theodore Y. Ts'o
On Mon, Jun 04, 2018 at 12:16:16AM +0200, Peter Backes wrote: > > Verifying the commit ID by itself wouldn't be any less efficient than > before. Admitteldly, it wouldn't verify the author and authordate > integrity anymore without additional work. That would be some overhead, > sure, and

Re: GDPR compliance best practices?

2018-06-03 Thread Theodore Y. Ts'o
On Sun, Jun 03, 2018 at 10:52:33PM +02h00, hPeter Backes wrote: > But I will take your message as saying you at least don't see any > obvious criticism leading to complete rejection of the approach. If you don't think a potential 2x -- 10x performance hit isn't a blocking factor --- sure, go

Re: GDPR compliance best practices?

2018-06-03 Thread Theodore Y. Ts'o
On Sun, Jun 03, 2018 at 09:24:17PM +0200, Peter Backes wrote: > > He said: It would be a tyranny of lawyers. > > Let's not have a tyranny of lawyers. Let us, the engineers and hackers, > exercise the necessary control over those pesky lawyers by defining and > redefining the state of the art

Re: GDPR compliance best practices?

2018-06-03 Thread Theodore Y. Ts'o
On Sun, Jun 03, 2018 at 07:46:17PM +0200, Peter Backes wrote: > > Let's be honest: We do not know what legitimization exactly in each > specific case the git metadata is being distributed under. It seems like you are engaging in something even more dangerous than a hardware engineering