Hi
On Thu, Feb 19, 2015 at 2:24 PM, Lukas Jirkovsky l.jirkov...@gmail.com wrote:
On 19 February 2015 at 21:42, Doug Newgard scim...@archlinux.info wrote:
You can't. If upstream provides a checksum, that gives you some verification,
but since github doesn't, there's no way to verify any of it.
On 19/02/15 11:39 PM, Mark Lee wrote:
On 02/19/2015 05:46 PM, Mark Lee wrote:
On 02/19/2015 05:24 PM, Lukas Jirkovsky wrote:
On 19 February 2015 at 21:42, Doug Newgard scim...@archlinux.info wrote:
You can't. If upstream provides a checksum, that gives you some
verification,
but since
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/20/2015 03:27 AM, Daniel Micay wrote:
On 19/02/15 11:39 PM, Mark Lee wrote:
On 02/19/2015 05:46 PM, Mark Lee wrote:
On 02/19/2015 05:24 PM, Lukas Jirkovsky wrote:
On 19 February 2015 at 21:42, Doug Newgard
scim...@archlinux.info wrote:
On 20/02/15 09:03 AM, Mark Lee wrote:
The checksums are there for integrity. The GPG signatures only confirm
the packager built the package. My question is if a packager's
PKGBUILD fails a checksum and the license is GPL, how does the
packager fullfill their requirement to provide the source
On 20/02/15 09:03 AM, Mark Lee wrote:
No... the integrity check not matching is not because an
out-of-tree source tree was used. The checksums are certainly not
there to improve security, that's what GPG signatures are for.
The checksums are there for integrity. The GPG signatures only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I understand that the metadata changed which changed the checksum,
but that doesn't really change the question of what to do with
source code versioning systems that have changing checksums and the
need to supply source code for GPL projects.
Hi,
On 02/20/2015 03:22 PM, Daniel Micay wrote:
On 20/02/15 09:03 AM, Mark Lee wrote:
I understand that the metadata changed which changed the checksum, but
that doesn't really change the question of what to do with source code
versioning systems that have changing checksums and the need to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/20/2015 09:22 AM, Daniel Micay wrote:
On 20/02/15 09:03 AM, Mark Lee wrote:
The checksums are there for integrity. The GPG signatures only
confirm the packager built the package. My question is if a
packager's PKGBUILD fails a checksum
On 20/02/15 09:41 AM, Florian Pelz wrote:
Hi,
On 02/20/2015 03:22 PM, Daniel Micay wrote:
On 20/02/15 09:03 AM, Mark Lee wrote:
I understand that the metadata changed which changed the checksum, but
that doesn't really change the question of what to do with source code
versioning systems
On Fri, Feb 20, 2015 at 3:53 PM, Mark Lee m...@markelee.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Checksums aren't sources, they are a method of verifying the integrity
of sources. In other words, while different files can have the same
md5sum (hash collision), a failed
On 20/02/15 10:04 AM, Martti Kühne wrote:
On Fri, Feb 20, 2015 at 3:53 PM, Mark Lee m...@markelee.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Checksums aren't sources, they are a method of verifying the integrity
of sources. In other words, while different files can have the
On Fri, Feb 20, 2015 at 4:09 PM, Daniel Micay danielmi...@gmail.com wrote:
On 20/02/15 10:04 AM, Martti Kühne wrote:
You should really just tell upstream to sign their releases, because it
wipes out the attack vector instead of just making it possible to audit
whether a MITM attack on the
On 02/19/2015 04:32 PM, Marcel Kleinfeller wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
[marcel@oompf ~]$ md5sum archlinux-2015.02.01-dual.iso
3d6a54886230649a049a9d431e03bbba archlinux-2015.02.01-dual.iso
Everything should be fine with this mirror.
Marcel, All,
I am now
On 20/02/15 10:22 AM, Florian Pelz wrote:
On 02/20/2015 03:59 PM, Daniel Micay wrote:
The vast majority of users make use of the binary packages and the
checksums do absolutely nothing to secure the main attack vector
which is a compromise of the sources downloaded by the packager. It
is
On 20/02/15 09:53 AM, Mark Lee wrote:
On 02/20/2015 09:22 AM, Daniel Micay wrote:
On 20/02/15 09:03 AM, Mark Lee wrote:
The checksums are there for integrity. The GPG signatures only
confirm the packager built the package. My question is if a
packager's PKGBUILD fails a checksum and the
On 20/02/15 10:26 AM, Mark Lee wrote:
However, the issue still stands regarding checksums. Perhaps packages
with metadata changes should just not include checksums? Or, they could
just link to the sources.archlinux.org in those cases with checksums.
Ideally, devtools would generate a source
On 02/20/2015 03:59 PM, Daniel Micay wrote:
The vast majority of users make use of the binary packages and the
checksums do absolutely nothing to secure the main attack vector
which is a compromise of the sources downloaded by the packager. It
is only relevant to the tiny minority of people
On 02/20/2015 10:22 AM, Florian Pelz wrote:
On 02/20/2015 03:59 PM, Daniel Micay wrote:
The vast majority of users make use of the binary packages and the
checksums do absolutely nothing to secure the main attack vector
which is a compromise of the sources downloaded by the packager. It
is
David C. Rankin wrote:
Is there anything other than hardware that could account for this? The
drive in the laptop is
[etc.]
Bad RAM is a common source of data corruption along those lines. Try booting a
memtest disc?
--- Drake Wilson
On 02/20/2015 04:51 PM, Daniel Micay wrote:
PKGBUILD checksums provide *zero*, yes *zero* security for the case
that matters most, which is the build done by the packager. It does
provide the ability for other people to verify that a MITM attack
was not used to target a specific packager...
On Fri, Feb 20, 2015 at 06:54:10PM +0100, Florian Pelz wrote:
On 02/20/2015 04:51 PM, Daniel Micay wrote:
PKGBUILD checksums provide *zero*, yes *zero* security for the case
that matters most, which is the build done by the packager. It does
provide the ability for other people to verify
On 20/02/15 12:54 PM, Florian Pelz wrote:
On 02/20/2015 04:51 PM, Daniel Micay wrote:
PKGBUILD checksums provide *zero*, yes *zero* security for the case
that matters most, which is the build done by the packager. It does
provide the ability for other people to verify that a MITM attack
was
On 02/20/2015 07:22 PM, Dolan Murvihill wrote:
CAs can, and have, deliberately issued fraudulent certificates.
TrustWave is the only one that has been discovered doing this ---
and that, only because they came forward on their own years after
the fact. The security community generally agrees
23 matches
Mail list logo
