On Wed, Sep 3, 2014 at 1:45 PM, R P Herrold <[log in to unmask]> wrote:
> On Wed, 3 Sep 2014, Nico Kadel-Garcia wrote:
>
>> It's quite galling: the current semi-manual re-assembly of
>> local branches, based on "git log" entries, is winding up
>> lauded as sufficient and superior because, frankly, it's the
>> only thing that's currently supported.
>
> Nico
>
> I get it -- you are unhappy about unsigned SRPMS.  I am
> located in the US and so readily subject of the reach the
> upstream as a target for litigation on perceived EULA / terms
> of use / etc violations.  I won't be exposing such a tool
> publicly, but then ...

I'm in the Boston area, and copyright is generally international.

> If you (seemingly offshore from the upstream) really cannot
> afford the funds for a subscription, and will do the coding of
> a mrepo / satellite / whatever proxy to retrieve the signed
> sources, please ... pass the hat, buy a subscription, and just
> sit down and write the code.  It would seem (but you should
> satisfy yourself) that your downside risk is that they will
> turn off such a subscription

Lord, no, I can't do that! While many upstream vendor tools are GPL
based or open source, that would put me right in the republication
business! Red Hat is being good citizens, publishing their code in
easily accessible format for CentOS and Scientific Linux and
developers to use without registration required. It would be
discourteous, as well as illegal, to republish their tools this way
without at least clearing trademarks, etc.

If you have a license and need an internal mirror, for my licensed
environments, I do publish a tool for just that purpose.

    https://github.com/nkadel/nkadel-rsync-scripts/blob/master/reposync-rhel.sh

A mirrored repository to disassemble and check against the git
repository for component matches is..... feasible, and I have already
done so for a couple of SRPM's, but only on an individual basis, not
wholesale.

> But is is not productive (for you) to carp over and over
> without taking steps to address your concern, nor (for others)
> reading mailing lists to wade through 're-runs' of your
> concern

I've done what I can for now, trying to convince the maintainers of
git.centos.org that the security concern is well founded. And I only
bring it up when a new thread ties so closely to it. This one did.