From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 034074DA04; Wed, 13 Nov 2024 11:40:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731498017; cv=none; b=HXZwwSnP56/5VeMFO5yu4oMeqI4uh0TEYaUQ/wInrpQ+AS8xYDGOUDJyjBIk2JsjwOVnP7XVoD51h+yu8R9vbvJWUbcveXuWcE33IIhY5iyGoDtzyfFTftBLBvFNsTTSLLIvbNHmurWzmH6mvR8/hTfU5UWE6AJNlgwjNElonaE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731498017; c=relaxed/simple; bh=pH/drVezZjQoNO7PGRj8CNyoPiRUnDsx5whFrgim2qM=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=MCCWLFN03gdOCjkqKyK90enXHhTtMSKFHna+YgI82k/b0Q/7flGKzvReauXp4RikFTF0JvoVsfrMJEj6qDFZxOW+o28pArpYAfxxHYVpcC0gy+CwCBtmLYlnKvqonIauEac4zovz0/cldQmTKgAvRZctHI0hoQc0P8Ch5g6FTjI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=f73l2Dsa; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="f73l2Dsa" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DADB0C4CECD; Wed, 13 Nov 2024 11:40:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1731498016; bh=pH/drVezZjQoNO7PGRj8CNyoPiRUnDsx5whFrgim2qM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=f73l2DsaHFlFCg+vhwK6wQQGIxbfM/odVdFrAYPJDVq5ORCmLk7iAJboZ+NUM/awb WAnCoSywzazRUdsa233qJeiBw3BmGQLI53sLKLiErkFqy9KOIDRrGBpSZn1Dx895d6 nnOmehKY1ujDoukyneQlxU0mP1wlFeQUs91B7vnQVypZYNtN7t0Wn129TNBO25ZSCp GK9QOjzvElvo1EEJSsZbJ5XE8yOTAncUHZI3+WzUbM5rpcZEpmRpHPS5B25RtxOcmV eNGQr1iY9InOjMzLi8wKwQyy0X0vq3ZzF9Ob+d8M+QD0Vatb4JASUNUavaJvhCfo4A Vw3wwglvM0Guw== Date: Wed, 13 Nov 2024 12:40:10 +0100 From: Mauro Carvalho Chehab To: Simona Vetter Cc: Thorsten Leemhuis , Laurent Pinchart , Jonathan Corbet , workflows@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1] docs: reminder to not expose potentially private email addresses Message-ID: <20241113124010.7e7edaa1@foz.lan> In-Reply-To: References: <20241113102619.GC29944@pendragon.ideasonboard.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: workflows@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Em Wed, 13 Nov 2024 11:59:39 +0100 Simona Vetter escreveu: > On Wed, 13 Nov 2024 at 11:55, Thorsten Leemhuis wrote: > > > > On 13.11.24 11:26, Laurent Pinchart wrote: > > > On Wed, Nov 13, 2024 at 09:35:03AM +0100, Thorsten Leemhuis wrote: > > >> Remind developers to not expose private email addresses, as some people > > >> become upset if their addresses end up in the lore archives or the Linux > > >> git tree. > > >> > > >> While at it, explicitly mention the dangers of our bugzilla instance > > >> here, as it makes it easy to forget that email addresses visible there > > >> are only shown to logged-in users. > > >> > > >> These are not a theoretical issues, as one maintainer mentioned that > > >> his employer received a EU GDPR (general data protection regulation) > > >> complaint after exposuring a email address used in bugzilla through a > > >> tag in a patch description. > > >> > > >> Signed-off-by: Thorsten Leemhuis > > >> --- > > >> Note: this triggers a few checkpatch.pl complaints that are irrelevant > > >> when when ti comes to changes like this. > > >> > > >> v1: > > >> - initial version > > >> --- > > >> Documentation/process/5.Posting.rst | 17 +++++++++--- > > >> Documentation/process/submitting-patches.rst | 27 +++++++++++++++++--- > > >> 2 files changed, 36 insertions(+), 8 deletions(-) > > >> > > >> diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst > > >> index b3eff03ea2491c..1f6942948db349 100644 > > >> --- a/Documentation/process/5.Posting.rst > > >> +++ b/Documentation/process/5.Posting.rst > > >> @@ -264,10 +264,19 @@ The tags in common use are: > > >> - Cc: the named person received a copy of the patch and had the > > >> opportunity to comment on it. > > >> > > >> -Be careful in the addition of tags to your patches, as only Cc: is appropriate > > >> -for addition without the explicit permission of the person named; using > > >> -Reported-by: is fine most of the time as well, but ask for permission if > > >> -the bug was reported in private. > > >> +Note, remember to respect other people's privacy when adding these tags: > > >> + > > >> + - Only specify email addresses, if owners explicitly permitted their use or > > >> + are fine with exposing them to the public based on previous actions found in > > >> + the lore archives. There is no comma between "addresses" and "if". "previous actions" sounds a little to vague. Also, the text doesn't cover everything, as lore archives may contain gaps. I would, instead be clear: - Only specify email addresses if owners explicitly permitted their use or if such e-mail was previously used publicly for Linux contributions, which can be checked by looking at the lore archives and at the git log. I added "git log there" because, in practice, nobody has the time to double-check what e-mails are public: developers rely that scripts/checkpatch.pl will check git log when creating the Cc: list. Thanks, Mauro