From: Borislav Petkov <bp@alien8.de>
To: Konstantin Ryabitsev <mricon@kernel.org>
Cc: Leonard Tse <xiehao5@gmail.com>,
ftpadmin@kernel.org, linux-kernel@vger.kernel.org,
greg@kroah.com, leoli@freescale.com, triplex@zh-kernel.org,
tshibata@ab.jp.nec.com, k-keiichi@bx.jp.nec.com,
minchan.kim@gmail.com
Subject: Re: [PATCH]URL is unavailable
Date: Thu, 13 Sep 2012 15:55:29 +0200 [thread overview]
Message-ID: <20120913135529.GA23485@x1.osrc.amd.com> (raw)
In-Reply-To: <5051E12F.80001@kernel.org>
On Thu, Sep 13, 2012 at 09:35:43AM -0400, Konstantin Ryabitsev wrote:
> On 13/09/12 05:32 AM, Borislav Petkov wrote:
> > My memory is hazy on this, but after the move, what's the policy on
> > enabling users.kernel.org or userweb.kernel org or some other user web
> > serving thing? I vaguely remember that we don't want to do this anymore
> > but I'm not sure.
>
> Well, as such system would be the largest security risk, it's
> understandable that we're, err... reticent to have it up anywhere near
> the rest of the infrastructure. :) We do have ssh enabled on two systems
> that require git and release management, but anyone ssh'ing in never
> gets a real shell and is severely locked down with SELinux.
>
> > In any case, if we do, it would probably be better to have a whole
> > different machine for such stuff and let users upload their stuff again
> > without touching the old backups at all...
>
> A better question is -- what is the problem we are trying to solve? We
> are not in the business of providing free web hosting -- our aim is to
> facilitate kernel development. We already provide a mechanism for git
> trees and release tarballs. What is lacking is a simple way to publish
> documentation -- it can be currently done with kup, but it's poorly
> suited for uploading and managing many small files.
>
> We already have a skeleton implementation of pulling such docs from git
> trees (e.g. git docs are published that way). It's on my list of things
> to extend this to a more universal and versatile system that would make
> it easy for anyone to publish arbitrary documentation via their git
> access -- perhaps on a subdomain like docs.kernel.org/treename/[etc]. We
> can even require the use of "git tag -s" -- this will give us both
> adequate security and history of changes.
>
> I think this would be a better approach than allowing unfettered ssh
> access and upload of arbitrary files.
You're right, I agree with all that but what happens if someone wants
to really upload an arbitrary file - say a tarball of stuff he's been
working on but it is not ready for a repo yet. Or a microcode blob or
whatever. Or even a doctored picture of Alan Cox celebrating the queen
:-)
I think this was the main reason behind userweb but I guess we're better
off finding different storage for stuff like that now.
Thanks.
--
Regards/Gruss,
Boris.
prev parent reply other threads:[~2012-09-13 13:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-12 15:51 Leonard Tse
2012-09-12 16:03 ` Borislav Petkov
2012-09-12 22:35 ` Leonard Tse
2012-09-13 1:13 ` Konstantin Ryabitsev
2012-09-13 9:32 ` Borislav Petkov
2012-09-13 13:35 ` Konstantin Ryabitsev
2012-09-13 13:55 ` Borislav Petkov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120913135529.GA23485@x1.osrc.amd.com \
--to=bp@alien8.de \
--cc=ftpadmin@kernel.org \
--cc=greg@kroah.com \
--cc=k-keiichi@bx.jp.nec.com \
--cc=leoli@freescale.com \
--cc=linux-kernel@vger.kernel.org \
--cc=minchan.kim@gmail.com \
--cc=mricon@kernel.org \
--cc=triplex@zh-kernel.org \
--cc=tshibata@ab.jp.nec.com \
--cc=xiehao5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome