Mock build of GO program fails
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 build the package locally with network access but when I run mock the build always fails with the following message: go build -ldflags="-B 0x8fed0b1e64bd7424a5e5bae0774d74d15f24add1" ./cmd/ssh-chat go: github.com/alexcesaro/log@v0.0.0-20150915221235-61e686294e58: invalid version: git fetch -f origin refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /builddir/go/pkg/mod/cache/vcs/016624ec8fded143255b88378860b2bc8e5ac782133a7bec312d6e53ef83caea: exit status 128: fatal: unable to access 'https://github.com/alexcesaro/log/': Could not resolve host: github.com make: *** [Makefile:12: ssh-chat] Error 1 It's clear that mock cannot access the network. So the source code which normally will be downloaded must be provided as SOURCE files. Can this be resolved by changing the spec file. If so, how? Or must the source code be chaged where the imports happen? import ( "bufio" "fmt" "io/ioutil" "net/http" "os" "os/signal" "os/user" "strings" "github.com/alexcesaro/log" "github.com/alexcesaro/log/golog" flags "github.com/jessevdk/go-flags" "golang.org/x/crypto/ssh" sshchat "github.com/shazow/ssh-chat" "github.com/shazow/ssh-chat/chat" "github.com/shazow/ssh-chat/chat/message" "github.com/shazow/ssh-chat/sshd" ) I have uploaded all relevant information to: https://senderek.ie/fedora/ssh-chat Thanks in advance for any help. Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Suspicious file in /usr/lib64
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: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Suspicious file in /usr/lib64
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 build on the PPC64LE testsystem but I couldn't get the test system to perform like the failed build. Has anyone seen something similar with such an exclusive build failure on PPC64LE? Can anyone point me into the direction how to handle this (except waiting for the problem to go away). Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Kerberos: Bug or Feature ?
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 Fedora does instead. What I found confuses me. In the directory /etc/krb5.conf.d you'll find a file named "crypto-policies" (which is a link actually) with the following content: [libdefaults] permitted_enctypes = aes256-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 camellia256-cts-cmac aes128-cts-hmac-sha1-96 aes128-cts-hmac-sha256-128 camellia128-cts-cmac I thought that the entries under permitted_enctypes would limit the cipher-suite that would be acceptable by my brand-new F28 installation. So I deleted everything except the two cipher-suites I want to allow and changed the content of this file to: [libdefaults] permitted_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 The result (after a fresh reboot) was that authentication to FEDORAPROJECT.ORG shows that still the sha1 ciphersuite is being used. The same applies to my old F26 installation. $ klist -e Ticketzwischenspeicher: KEYRING:persistent:1000:1000 Standard-Principal: sende...@fedoraproject.org Valid starting Expires Service principal 10.05.2018 11:28:27 11.05.2018 11:25:08 HTTP/id.fedoraproject@fedoraproject.org erneuern bis 17.05.2018 11:25:08, Etype (Skey, TKT): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 10.05.2018 11:28:27 11.05.2018 11:25:08 HTTP/id.fedoraproject.org@ erneuern bis 17.05.2018 11:25:08, Etype (Skey, TKT): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 10.05.2018 11:25:14 11.05.2018 11:25:08 krbtgt/fedoraproject@fedoraproject.org erneuern bis 17.05.2018 11:25:08, Etype (Skey, TKT): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 Does anyone here know why the Kerberos crypto-policy does not do what it's supposed to do? Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.
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 know why it is seen as important and what is at stake if it isn't fixed. This info should be visible on the web page to help focussing the efforts to those bugs which may have the most impact. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 System Wide Change: OpenSSL 1.1.0
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 use of crypto to one of these > three libraries and avoid any additional ones with exception of > libgcrypt for gnupg2. This assumption ignores the fact that Cryptlib has joined Fedora and has every right to be included in that list. https://admin.fedoraproject.org/pkgdb/package/rpms/cryptlib/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: A new way of writing secure code
> 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 usage of SSL and TLS cryptographic protocols that are enforced system-wide. Each application being added in Fedora must be checked to comply with the policies. Currently the policies are restricted to applications using GnuTLS and OpenSSL," Why do you think any code that uses cryptlib does not comply with this? > Until that happens, software using it will have inconsistent > crypto settings and thus I would not recommend using that lib in > Fedora. One of the main benefits of using cryptlib is the fact that consistent crypto settings ARE USED, because the High-level interface makes it almost impossible that an inexperienced crypto programmer will be able to screw up the system inadvertently by choosing the wrong parameters. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: A new way of writing secure code
> On 07/04/2016 07:40 AM, Ralf Senderek wrote: > Do you have suggestions how to comply with the anti-SaaS part of the > cryptlib license in an automated fashion? There is no "anti-SaaS part of the cryptlib license" The additional clarification states that there cannot be any exception to the requirement to provide source code to the user. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
A new way of writing secure code
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 offers a High-level interface that makes it very easy for inexperienced crypto programmers to write secure code. The excellent cryptlib manual is full of code examples for a number of languages, including C, Java, Python and Perl. Please have a look. (http://www.cypherpunks.to/~peter/manual.pdf) Ralf. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Checking signatures on package source tarballs
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 fact that some upstream sign their code (in particular when the code is security critical) means that they're willing to take responsifility for the code in the form "they signed it off". It is sometimes very easy to ruin a secure system by modifying it (with a patch or some code in the spec file doesn't matter). That's why I thought it might make sense for the packager to take responsibility for his modifications by signing them. The changelog don't really reflect the modifications in enough detail. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Checking signatures on package source tarballs
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 into the public key are by no means optional. 2) Patches, that are applied to the signed (and checked) source must also be signed by the packager and checked in %prep. From an ordinary Fedora user's point of view modifications of the trusted source code should also be properly attributed to the one who modified. If upstream signs its code it is for the purpose to better distinguish original and patched code. So in order to add accountability, patches must be signed as well. 3) While the new tarball can be a URL, the public key ring cannot be allowed to be downloaded, it must be produced by the packager and added as a file to the SOURCE directory. We have to ensure the equivalent to "certificate pinning" in browsers here, so that a (possibly MITMed) false source tarball can be checke with a key that has been sitting in the GIT for a long time, and not just been downloaded alongside the false tarball. Zbigniew Jędrzejewski-Szmek wrote: > The alternative of SHOULD would mean that the maintainer is not sure > if the new tarball can be trusted but goes ahead anyway. In that > situation I'd prefer she waits until it *can* be verified. > > Zbyszek You're right, its not easy to come up with a valid excuse not to check the signature, when upstream clearly wants to use it, and highlights this fact on their website. I'm just not sure how many packagers would get into trouble if the signature check becomes a requirement for the package to go ahead. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Checking signatures on package source tarballs
> 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 SHOULD ask upstream to provide it if it is > missing [1]. I think we should follow this pattern for signatures. I think MUST or SHOULD should be decided in light of the threat model. If upstream signs the source code, what are they trying to prevent? Most likely they don't want anyone else to be able to produce updated source code that looks legitimate. Now, what if there is a new updated source code without a matching signature on the upstream website? Upstream clearly does not want this code to go into Fedora. What, if there is a new updated source code with a matching signature and a new key? At that point the packager has got some work to do, because it's not clear what that means. a) if the new key is signed by the old code signing key, prepare a new keyring and go ahead. b) if the new key is self-signed because upstream has had an incident in which the sole control over the old key's private key may have been lost, then an attacker could create a new key that looks legitimate to the packager like a). A packager cannot tell a) from b) if he does not make close contact to upstream about the new key. No automation is possible here. In case of an incident where the private key may be compromized, upstream is required to build the trust into the new key from the ground up. As these cases can be quite complicated and would need some serious actions on behalf of the packager I think at the moment everything speaks in favour or SHOULD, because we don't have a bullet-proof procedure everyone can follow. But that's only my 2c. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Checking signatures on package source tarballs
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 the packager (including the use of gpg). -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Checking signatures on package source tarballs
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 only makes sense if you are sure you're using the correct public key. So the packager, who is supposed to work closely with upstream, MUST make sure that he has the correct public key form first-hand knowledge before he can include it in the spec file as %(SourceN) for %prep. This is as important as checking the source code for licensing files and it would be much more than the average Joe would do if he'd gonna check the source himself. Sometimes the packager and upstream is even the same, so making sure the right public key is being used will be quite easy. Having said the above, I also advocate a SHOULD instead of a MUST in the guidelines as providing a signature with the source tarball is voluntary for upstream and should be viewed as an additional means to maintain the integrity of the code that should be honoured in the spec file. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Checking signatures on package source tarballs
> 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 package everything that makes up the source after extraction. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: More prominent link to verification hashes
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 corporations or that Red Hat sponsors this project assume that if Red Hat were paid enough money they would change the data any time. We put it in archive.org and people wonder how we can tell it isn't impersonated by some other site or that someone else isn't changing it. We put it in lwn.net and people wonder how they will know where to find it or why we didn't choose reddit/slashdot/etc/etc. We get google to host it and people wonder all of the above. Stephen, please bear in mind that it's not a measure to make everyone happy, publishing the fingerprint(s) is meant to prevent faking of the key. And this is much more than providing only self-signed keys without linking them to first-hand knowledge about their authenticity. You don't have to come up with a solution that suits everyone, as long as it is enough to make faking a really hard job for anyone. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: More prominent link to verification hashes
> 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 visible to many people with a need to verify. - a place that is known for publishing cross-checked, reliable information Hope that helps to find such places. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: More prominent link to verification hashes
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 fingerprint. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: More prominent link to verification hashes
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 password to unlock the key. The signing server manages access. There is exactly two copies of the private key, one embeded in encrypted storage on the signing server and a backup of the encrypted storage on the backup server. It has been designed to allow the granting and revocation of access without the need for having a copy of the private key. https://fedorahosted.org/sigul/ is the software we use Dennis Thank you for providing this valuable information about the handling of the private key that enables Fedora ISO signing. This information should be shared and highlighted as it is helping to create trust in the use of this key. As a personal request, would you be so kind as to confirm the fingerprint here (and maybe somewhere else), please. Thank you very much. Ralf -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: More prominent link to verification hashes
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 public key with this fingerprint when I asked for the Fedora 24 signing key: pub 4096R/81B46521 2015-07-25 Fedora (24) Key fingerprint = 5048 BDBB A5E7 76E5 47B0 9CCC 73BD E983 81B4 6521 This is the important part, you state that you have access to the server that uses the private key for 4096R/81B46521. You may have first-hand knowledge how the persons using this key protect this private key and you have even knowledge of these person's trustworthiness and professionalism. That and only that constitutes the value of your signature as opposed to mine if I had signed the key. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: More prominent link to verification hashes
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 from DNS I was very clear in saying fingerprint not keys. The original key file from the website contains only self-signed keys. The only way to know if these are valid is to check the fingerprint. Also all recent Fedora keys were signed by me. So how many different places do we need to make it secure? I am also very interested in making this secure, but adding more random places to look does not help unless people a actually looking there. Printing the fingerprint in prominent places makes faking the key nearly impossible, even if the ordinary user doesn't look there. And since you did not notice that I signed the GPG keys, I guess you did not look much as well. You didn't sign it in the download file from the verify page. Signing a key only helps if it is an assurance that the signer has checked the fingerprint. I could have signed the keys as well, but I didn't because I don't know anything about the fingerprint from first-hand. If you have a valid means of checking the fingerprint with the creator of the key and publicly confirm the fingerprint on the mailing list, this would be a step forward. Btw before suggesting what to provide, maybe think of the instructions for users that would explain how to verify the keys They are already asking the user on the verify page to run a gpg command, displaying the fingerprint is as easy as that. If you think you can improve things by signing keys, then take Gregory's advice and create a long-term signing key and add it's signature to new fedora release keys. AND print the fingerprint of this one key in many prominent places. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: More prominent link to verification hashes
> 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 visible way that risks their good reputation if the information turned out to be incorrect. These statements would then be the foundation of trust in what the Fedora 24 key signs. > Combined with having the key on getfedora.org, it at least provides a > measure of protection against our site being compromised. It also has > the benefit of, if someone knows of any Fedora devs on Twitter or > another service, they can follow the web of social-service trust. This > isn't as good as if they had a direct path to the Fedora WoT through > normal signatures, but it's much more likely to actually occur. Yes all of this, please. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: More prominent link to verification hashes
> 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 site is compromised if the fingerprint is independently recorded many times elsewhere. BTW, pointing to a key server is not the way to convince anyone. A key server is a convenient way to get keys, not a tool to assure their authenticity. So I don't think that there is much of an alternative other than someone stepping in and provide some first-hand knowledge about the key. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: More prominent link to verification hashes
> 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 kept offline and not > compromised-- and the instructions should have them verify > accordingly. But this would require the keys being shipped are signed > with prior releases key (or some static key signing key), and existing > users being told to check for that. While signing new keys with old release keys would certainly help to make the attacker's job harder, it doesn't solve the trust problem. The one thing people would have to check is the fingerprint. That in itself would be sufficient even if the new key is not being signed by another one. The current download gives a fingerprint for the new Fedora 24 key: Key fingerprint = 5048 BDBB A5E7 76E5 47B0 9CCC 73BD E983 81B4 6521 and this could as well be manipulated by the attacker who has access to the web server. Given that this fingerprint is actually correct, it would help if it was printed off-line in any publication authorized by Fedora. The use and distribution of the fingerprint to various places showing consistently the same information would make it near impossible to fake the key. If that had been done beforehand, all a new, ordinary user would have to do is to check this one fingerprint. So please can someone convince me that the key above is really the right one? If so, using this fingerprint anywhere would help to build the trust that is not there yet. > It would also be preferable if the > keys were distributed on a separate server on a different network, so > that https would protect users that didn't/couldn't verify the > authenticity of the downloaded keys. Using HTTPS does not at all verify that the information you get is correct, it assures you of the correct origin, if https actually works as advertised, which in many cases it doesn't, But Red Had could publish the Fedora fingerprint as well on their servers. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Self introduction: Ralf Senderek
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 key management and the source code should be as auditable as possible. Even though I include the full cryptlib at the moment with no changes or patches to the source code, I only need a much reduced, local version. That's why I provide the cryptlib so-file in the location where it is needed by the cryptobone package for exclusive use by the root user. As you may know the cryptlib source code is designed to run everywhere and provides a number of test programs (and an excellent documentation too) so that providing a separate library package must include all these excellent stuff. I'm willing to tackle this task when my first package is done. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Self introduction: Ralf Senderek
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 called Crypto Bone which combines usability and security. I tried to make this system as usable as possible with an new approach to encryption key management, because I realized, that complex key management is the main reason for ordinary users not to use encryption. And I want to change that. On the other hand, I need to secure the encryption keys in a way that enables the ordinary user to take control himself. The result - the cryptobone - is now finished and I thought I should package this software for the Fedora repository. So I requested a review of the new cryptobone package: https://bugzilla.redhat.com/show_bug.cgi?id=1310092 And, of course, I'm seeking a sponsor for this package, because I'm a new contributor. During the development of the cryptobone software, I decided to reduce the cryptographic core to a bare minimum and to use Peter Gutmann's cryptlib as the only dependency for my own crypto code. I hope that including cryptlib in my own package will enrich the Fedora code base. And I hope to be able to make secure messaging a reality for many users who need it. Thank you for your interest and feedback. Ralf. PGP key: https://senderek.ie/keys/encryptionkey.asc (2546174A) -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
