Upstream Package/Repo Mainainer

[indolering]

We build and support NameCoin on RedHat and CentOS for our own needs (http://www.securedolphin.com). We also blogged on changes, necessary to compile and run NameCoin on CentOS and RedHat (http://securedolphin.com/blog/running-n ... -redhat-62 and http://securedolphin.com/blog/building- ... -centos-62). We'd be happy to take on the RedHat/CentOS package maintenance as expression of our gratitude to the NameCoin community.

BTW, it seems that CentOS/RedHat builds are failing to produce RPM due to dependency package naming problem (the BerkleyeDB is called differently on CentOS/RedHat). I imagine there are a few more problems that would need to be resolved before the build yields an RPM.

You are welcome to do so, just ensure that whatever repo you place it in allows for updates. Check out Conrads OBS-based for a working RPM.

At some point, we will have to figure out some security auditing for the various package management systems. With Conrad's OBS we just have to trust one maintainer and auditing is fairly simple since it downloads the binaries directly from Github. I know you have been working on getting it to build from source on RedHat, but is that the best way to go here?

[biolizard89]

We build and support NameCoin on RedHat and CentOS for our own needs (http://www.securedolphin.com). We also blogged on changes, necessary to compile and run NameCoin on CentOS and RedHat (http://securedolphin.com/blog/running-n ... -redhat-62 and http://securedolphin.com/blog/building- ... -centos-62). We'd be happy to take on the RedHat/CentOS package maintenance as expression of our gratitude to the NameCoin community.

BTW, it seems that CentOS/RedHat builds are failing to produce RPM due to dependency package naming problem (the BerkleyeDB is called differently on CentOS/RedHat). I imagine there are a few more problems that would need to be resolved before the build yields an RPM.

You are welcome to do so, just ensure that whatever repo you place it in allows for updates. Check out Conrads OBS-based for a working RPM.

At some point, we will have to figure out some security auditing for the various package management systems. With Conrad's OBS we just have to trust one maintainer and auditing is fairly simple since it downloads the binaries directly from Github. I know you have been working on getting it to build from source on RedHat, but is that the best way to go here?

Wait, we have binaries on GitHub? Link?

And yes, we need better auditing of the package systems. I've been playing around with reproducible builds; anyone want to help?

[indolering]

We build and support NameCoin on RedHat and CentOS for our own needs (http://www.securedolphin.com). We also blogged on changes, necessary to compile and run NameCoin on CentOS and RedHat (http://securedolphin.com/blog/running-n ... -redhat-62 and http://securedolphin.com/blog/building- ... -centos-62). We'd be happy to take on the RedHat/CentOS package maintenance as expression of our gratitude to the NameCoin community.

BTW, it seems that CentOS/RedHat builds are failing to produce RPM due to dependency package naming problem (the BerkleyeDB is called differently on CentOS/RedHat). I imagine there are a few more problems that would need to be resolved before the build yields an RPM.

You are welcome to do so, just ensure that whatever repo you place it in allows for updates. Check out Conrads OBS-based for a working RPM.

At some point, we will have to figure out some security auditing for the various package management systems. With Conrad's OBS we just have to trust one maintainer and auditing is fairly simple since it downloads the binaries directly from Github. I know you have been working on getting it to build from source on RedHat, but is that the best way to go here?

Wait, we have binaries on GitHub? Link?

And yes, we need better auditing of the package systems. I've been playing around with reproducible builds; anyone want to help?

I'm sorry, I misspoke, it's just downloading from the releases:

• https://github.com/namecoin/namecoin/releases
• https://github.com/namecoin/namecoin/ar ... on}.tar.gz

[indolering]

So, what is the best way to handle packing?

I would think that once Jeremy gets binaries up (especially Gitian builds) the simplest and most secure method (and most easily audit-able) would just be to have the package manager download the binary from Github. I believe binaries are the norm for apt-based systems, but does this violate some social norms regarding RPM?

[biolizard89]

So, what is the best way to handle packing?

I would think that once Jeremy gets binaries up (especially Gitian builds) the simplest and most secure method (and most easily audit-able) would just be to have the package manager download the binary from Github. I believe binaries are the norm for apt-based systems, but does this violate some social norms regarding RPM?

Bitcoin Gitian builds (and my libcoin Gitian builds) are statically linked, which is different from the convention of most package repos (which encourage shared linking). This is intentional: any failure to build a consensus is a security risk for users of blockchain applications, and if a routine bugfix in a dependency changes the consensus, then that needs to be subject to much more careful testing than with standard applications. Unfortunately, I've heard that some repo admins don't understand this, and have been rejecting Bitcoin packages that are statically linked.

It's not necessary to download the binary from a particular source; the hash of the binary is signed by multiple people, so if you have the public keys of the developers, you can download the binary from whatever seedy website you want. That's the whole point of Gitian.

[indolering]

Bitcoin Gitian builds (and my libcoin Gitian builds) are statically linked, which is different from the convention of most package repos (which encourage shared linking). This is intentional: any failure to build a consensus is a security risk for users of blockchain applications, and if a routine bugfix in a dependency changes the consensus, then that needs to be subject to much more careful testing than with standard applications. Unfortunately, I've heard that some repo admins don't understand this, and have been rejecting Bitcoin packages that are statically linked.

So this is the standard I should be pushing? I guess I will defer to you on this.

It's not necessary to download the binary from a particular source; the hash of the binary is signed by multiple people, so if you have the public keys of the developers, you can download the binary from whatever seedy website you want. That's the whole point of Gitian.

True, it just makes the process more complex to audit since I know have to ensure the code is checking a specific hash instead of just checking the link it uses. Although, I guess it would be better to enforce that checking somewhere.

[biolizard89]

Bitcoin Gitian builds (and my libcoin Gitian builds) are statically linked, which is different from the convention of most package repos (which encourage shared linking). This is intentional: any failure to build a consensus is a security risk for users of blockchain applications, and if a routine bugfix in a dependency changes the consensus, then that needs to be subject to much more careful testing than with standard applications. Unfortunately, I've heard that some repo admins don't understand this, and have been rejecting Bitcoin packages that are statically linked.

So this is the standard I should be pushing? I guess I will defer to you on this.

Don't defer to me, defer to the senior Bitcoin developers:

http://bitcoinmagazine.com/5858/linux-d ... d-bitcoin/

It's not necessary to download the binary from a particular source; the hash of the binary is signed by multiple people, so if you have the public keys of the developers, you can download the binary from whatever seedy website you want. That's the whole point of Gitian.

True, it just makes the process more complex to audit since I know have to ensure the code is checking a specific hash instead of just checking the link it uses. Although, I guess it would be better to enforce that checking somewhere.

You're not checking a specific hash, you're checking against a set of specific public keys. Checking this is important; otherwise a compromised web server would be able to distribute malware.

[pmc]

Bitcoin Gitian builds (and my libcoin Gitian builds) are statically linked, which is different from the convention of most package repos (which encourage shared linking). This is intentional: any failure to build a consensus is a security risk for users of blockchain applications, and if a routine bugfix in a dependency changes the consensus, then that needs to be subject to much more careful testing than with standard applications.

IMO this argument may have been valid in the early days(months?) of bitcoin, but it is long obsolete now. Today a multitude of different client implementations on different operating systems and different processor architectures happily coexist without any problems, and *that* means a much higher risk to blockchain coherency than linking an executable against different versions of the same library.

There's a number of good reasons why common package repositories discourage or even forbid static binaries, and IMO these outweigh the risks introduced through dynamic linking by far.