> If the site is compromised, most bets are off sadly.
Yes, for people who look only in one place, the manipulated web server.
But that is the reason why the fingerprint has to pop up in different places
where it is hard to fake. Even if this one user can be tricked, others can
discover that
> The Fedora team could get a profile and verify the key(s) through
> github, the Fedora and Red Hat web sites, the Fedora magazine twitter
> account, and by having the Fedora team all sign publicly.
Every little helps. The important step would be if the Fedora devs state the
fingerprints in a
On Tue, 23 Feb 2016, Till Maas wrote:
You can already get the keys at various places:
- Fedora website
- physical DVDs
- fedora-repos git repository
- fedora-repos RPM on kojipkgs
- fedora-repos RPM Fedora mirrors
- Fedora ISO images on Fedora mirrors
- Eventually DNSSEC protected
On Tue, 23 Feb 2016, Till Maas wrote:
I used my access to the signing server to verify the key before signing
it. But why is confirming the fingerprint here a step forward? Why would
someone search in this mailing list for the fingerprint of the gpg key?
FWIW, the signing server just gave me a
On Thu, 25 Feb 2016, Dennis Gilmore wrote:
No one has access to the private key. It lives on a server that has no
services running that listen for connections. There is a service that runs
on
it that talks to the signing bridge. That brokers all requests. Users with
access do not know the
On Thu, 25 Feb 2016, Dennis Gilmore wrote:
Which fingerprint? There is a number of keys
Dennis
The one you were referring to in your posting and which
an ordinary user would verify with:
gpg --list-keys --fingerprint 81B46521
Ralf
PS: if you had a long-term signing key it would be its
> On Sun, Feb 21, Gregory Maxwell wrote:
> The Fedora 24 key inside it is not signed by any other key.
...
> Authenticating keys is hard in general; but existing fedora users
> should at least be able to trust-on-first-use chain from earlier keys
> to later ones-- assuming the fedora keys are
Hello,
my name is Ralf Senderek, I'm a secure solutions designer. Linux is
my operating system since 1994. Over time I have developed and
released security related analysis and open source software on my
personal web site.
Recently, since Jan 2015, I am working on a secure message system
This is an obvious idea and I'm willing to do that.
But there are at least two reasons why I shouldn't do that as a first step.
The Crypto Bone is designed to use only a tiny fraction of the cryptlib system,
the symmetric encryption framework, because RSA/PKI and such isn't necessary
for the
> David Woodhouse wrote:
> If we need to repackage the tarball to remove patent-encumbered or otherwise
> illegal or non-redistributable files, we cannot do this.
I think , we can. Because the check in %prep should make sure that you've got
the real thing.
It doesn't require that you have to
> On Wed, Mar 30, 2016 at 02:26:59PM -0000, Ralf Senderek wrote:
> [snip the part I complete agree with]
...
> In fact signatures and license files are quite similar:
> our guidelines say that the license file MUST be installed if provided
> by upstream, and packagers SHOU
> What would be proper other places to confirm the fingerprint?
The following criteria might be reasonable:
- a place that has authority, that people might trust.
- a place that is hard to impersonate, that has some protection
against unauthorized use
- a place that is
On Mon, 7 Mar 2016, Stephen John Smoogen wrote:
Hope that helps to find such places.
Not really. Everything above is subjective. In the past, when I have
looked for sites that meet such criteria no one agrees that the place
meets such criteria.
We put it in redhat.com and people who hate
James Hogarth wrote:
> We trust our packagers to do a lot, we can trust them to add this to their
> packages if it helps them and for them to encourage it in their reviews if
> they find a signed archive provided upstream.
IMHO, this is the main point. Checking signatures automatically in %prep
Michael Catanzaro writes:
> Yeah, if this isn't automated SOMEHOW, I'm not going to do it, because
> I don't understand how to use GPG. I doubt I'm unusual in this
> regard
It cannot be automated, because it relies on using the correct public key,
which always has to be checked manually by
With my upstream hat on, I'm all for a MUST, because it's the only way that
upstream can control what goes into Fedora. Without checking signatures or
tarball hashes, it's too easy to end up with questionable code.
But the MUST has some implications:
1) The packager's trust-building activities
Zbigniew Jędrzejewski-Szmek wrote:
> I don't buy that reasoning. You sign stuff to prevent silent
> modification (because of malice or corruption), and not to track
> changes, we have better mechanisms for that.
Signing is much more than an integrity proof for which hash values would
suffice.The
> On Mon, 2016-07-04 at 05:40 +0000, Ralf Senderek wrote:
>
> But it would be code that will not comply with Fedora's crypto policies
> [0].
The crypto policies state:
"Since Fedora 21 (http://fedoraproject.org/wiki/Changes/CryptoPolicy) there are
policies for the usa
Dear developers,
for all who wish to add reliable encryption and authentication
services to their projects with ease, I'd like to draw your
attention to cryptlib, which is available in F23, F24, rawhide
and EPEL 7 stable repositories now. Cryptlib is not just another
function collection, but
Tomas Mraz wrote:
> My personal recommendation would be to follow the application's upstream
> recommendation.
This is of course the best approach, as the upstream project will have good
reasons to use a particular crypto foundation for the project.
> What we should strive for is to limit the
I think your proposal is useful, and it should be tested how far it'll get us.
There's one more thing I'd like to be included. If approved, the bug should
be categorized with respect to its impact on Fedora based on the discussion
that led to its approval as "important". I think it would help to
On the Cryptography mailing list
(http://www.metzdowd.com/pipermail/cryptography/2018-May/034150.html)
a question came up, regarding Kerberos' ability to replace passwords in a
secure way.
As John Gilmore pointed out, Kerberos on Ubuntu uses the outdated sha-1 hash,
so I tried to find out
what
Thank you Dan for investigating the cause.
Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Koschei has informed me that Cryptlib fails to build in F31 on the ppc64le
platform.
The build error is an upackaged file "/usr/lib64/st8bPtV6" which obviously
should never
exist at all.
https://kojipkgs.fedoraproject.org/work/tasks/6682/39076682/build.log
I've tried to reproduce the failed
I need a bit of assistance from a GO package expert.
I'm trying to package ssh-chat.
(https://bugzilla.redhat.com/show_bug.cgi?id=1819180)
ssh-chat is written in GO and it implements a custom SSH server
(on a different port) that provides a chat room instead of a shell.
I was successful to
25 matches
Mail list logo
