From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 702F081C03 for ; Thu, 25 Nov 2021 15:23:21 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 66543E9A3 for ; Thu, 25 Nov 2021 15:23:21 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 674FDE994 for ; Thu, 25 Nov 2021 15:23:20 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 2902C468F9; Thu, 25 Nov 2021 15:23:20 +0100 (CET) Message-ID: Date: Thu, 25 Nov 2021 15:23:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Thunderbird/95.0 Content-Language: en-US To: Thomas Lamprecht , Proxmox VE development discussion , Oguz Bektas References: <20211109141359.990235-1-o.bektas@proxmox.com> <20211109141359.990235-2-o.bektas@proxmox.com> <42391428-bd80-2d55-5cb6-7c8ecd97a3a8@proxmox.com> From: Dominik Csapak In-Reply-To: <42391428-bd80-2d55-5cb6-7c8ecd97a3a8@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 2.245 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -4.1 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Subject: Re: [pve-devel] [PATCH storage 1/2] download-url: reuse http_proxy from datacenter.cfg for https X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2021 14:23:21 -0000 On 11/25/21 15:06, Thomas Lamprecht wrote: > On 25.11.21 14:34, Dominik Csapak wrote: >> LGTM and works :) >> > > in general has the same issue as the ACME one from Stoiko, namely: > The original http_proxy was always for external resources (our repos/appliances, > subscription checks), but this and the ACME ones aren't necesarrily external, and > proxying them may break some stuff (not all enterprise setups have control over the > proxy to make it differ between internal/external resources) or be just undesired. > > What I'm missing on this and the acme patch is to actually step back and think > proxying in PVE/PMG through, what are the different use cases, how can they be > grouped sensible and exposed to the admin. At leas acknowledging something like > that in the commit message and giving some reasons about why that drawback is > accepted for now. > > I mean, Stoiko at least made it a per-acme-plugin decision if something should get > proxied through the datacenter configured proxy or not, but one may want to have > different too (albeit blowing it up per single smallest request-type is surely overkill). > > A https variant could be interesting too. > > One could imagine a format string like (disclaimer, made up on the spot): > > proxy: http=<>,https=<>,apply-on= > ( would be the original repo/appliances/subscriber coverage) > > just to note, i am not disagreeing with you but a small comment to this patch nonetheless: imho the current state is rather broken, for http urls it uses the proxy but not for https (isos are often hosted on https for now, e.g. debians) ans since at least one person[0] expected it to use the proxy in any case, i'd argue that for now this would be ok yes a more general approach with specific uses/allow/blocklist (however we want to implement this) would be better, but can still be done after this 0: https://bugzilla.proxmox.com/show_bug.cgi?id=3716