From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 3C9B52222B2 for ; Fri, 11 Apr 2025 17:10:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.9.28.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744391409; cv=none; b=sin7bYaptQEE2eX3Xmiqw4vsoter1Yh3KlbreAuXGR7zzdARTo7UDkinPTeB9S2dup32YVuRaOqmVbbhJEprh3N/d76CiqZ/QHED15MVIvill7pxxNUZLbo3tEOX6pHOmG7qoVIxdlRtxoJ9RRWrUWfTEOkEuvOvl63zSF7NWi8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744391409; c=relaxed/simple; bh=wYOHz4iKCECEx18AJ+taXyHaz9o+f2IPBrzKmoZUiac=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eXcmvlIJ+mmgXp1XzEIJwHhmTO2J7AEhvTGvHAk5I2EF3yuUMMp0c/RORH++tMD9sB44NezlJnNrUOV9CrAgiEb/minYYbootQqOLdlBbt+HDo61HGY2nFXDJAqQNSbJqSmQAqtwWTl6F7tGm/0zE0yyXa4YHI8GzUV6ewdLB/Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu; spf=pass smtp.mailfrom=mit.edu; arc=none smtp.client-ip=18.9.28.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mit.edu Received: from trampoline.thunk.org (pool-173-48-82-137.bstnma.fios.verizon.net [173.48.82.137]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 53BH9tfK031470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Apr 2025 13:09:56 -0400 Received: by trampoline.thunk.org (Postfix, from userid 15806) id AC0BB2E00E9; Fri, 11 Apr 2025 13:09:55 -0400 (EDT) Date: Fri, 11 Apr 2025 13:09:55 -0400 From: "Theodore Ts'o" To: Konstantin Ryabitsev Cc: Daniel Gomez , users@kernel.org, Luis Chamberlain , Chuck Lever , kdevops@lists.linux.dev Subject: Re: Forbidden requests for kernel.org/releases.json Message-ID: <20250411170955.GA1049077@mit.edu> References: <20250410-prophetic-elegant-fossa-a210fb@lemur> <20250411141800.GA648081@mit.edu> <20250411-amusing-flounder-of-vigor-bcab5e@lemur> Precedence: bulk X-Mailing-List: kdevops@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250411-amusing-flounder-of-vigor-bcab5e@lemur> On Fri, Apr 11, 2025 at 11:25:36AM -0400, Konstantin Ryabitsev wrote: > > For actual git requests it's fine if it just has git's default user-agent. > Obviously, we are not going to start blocking that. :) A while back we did get blocked once or twice; I assume because of some IP Address or IP range rate limit? The following day, the Kernel Compilation Service (KCS) VM had been shutdown and restarted with a new IP address, we had no trouble getting the new linux-next branch. Would having a different user-agent help in that case? > I'm fine with that as well -- just as long as you keep in mind that it can go > away at any time the way many Google things sometimes do. I'm also considering > running stable/next/mainline forks on several major forges as mirror-only > repos that are updated immediately after each push, so people can use them as > an alternative to googlesource. What I might do is to have my system silently rewrite git.kernel.org to one or more mirrors, with an automatic fallback if particular mirror disappears. That does have the risk if the mirror sticks around, but stops updating. I suspect that's less likely to happen, and presumably we can either (a) have some kind of hueristic for those branches which are known to be regularly updated, or (b) rely on a human to notice that particular failure case. - Ted