[arm-allstar] Arch vulnerabilities

Fri May 1 07:12:25 EST 2015

David:

Ok again downloaded and got the same sha1 as the last 5 times..  so it
seems that you are generating the sha1 from another source than I am..
my source is http://hamvoip.org/RPi2/RPi2_V1.0_Allstar.zip which is the
only link I know of.. so what is the difference here???  point me to the
correct source please..

As for zip.. don't have a version, as I am not on a windows box..
abandoned that OS totally about 15 years ago..  and don't run unzip
specific code..

I did not ask about the file size as the blocking factor of the
receiving file system will almost always show a different file size..
than you started with,  but checksums will always be correct, that is
the reason I asked for the checksum to start with..

Sitting here thinking (before hitting send) about this I just figured
out the checksum problem.. my mac as well as BSD systems unzips the file
when it is saved to the download directory directory leaving the actual
image file.. That image file is what I generated the sha1 against.. 
That is the SHA1 we should be providing to everyone.. as that is what
counts.. it would be the same across file systems.  Since I don't have a
system that doesn't automatically unzip, I can't generate a sha1 on the
actual zip file..   I think this is my problem in diagnosis only.. not
in actual operation.  The transport compression is not material to me..
nor should it be material to others..

The good news is that the image I dd-ed to the card actually appears
works just fine.. (it boots and runs haven't gone further)  I was
questioning the issues I was seeing..  what lead me there was the
extreme time it was taking with a bs=1m.   As for dd and the rest of the
system.. I have been using dd for to move images and files for the last
15 years.. so trust my abilities and hardware 100%.. 

If possible can you give me a sha1 of the actual image file, that alone
would verify that the starting image I have is 100% correct..

Security Issues:
Actually I was not asking about significant security issues.. I was
asking about any security vulnerabilities at all.. just look at the
patches that have occurred in just ssl this year..  I think I have
patched my server at least 10 times in the last 6 months.. (always from
source) I was concerned about you generating a new image for fixes and
updates. hence the question.. it's unknowns that bother me..  Knowing I
will have to track any fixes I put in place outside what you distribute,
or code I compile onto the system.. that is ok and not an issue, just
wanted to know how I should maintain my stuff on my box..  I am paranoid
about keeping code for critical things up to date.. others might think
that allstarlink is not a critical system, to me any server is critical
as otherwise it wastes my time fixing crap the hackers want on my
system.. thanks for the input.. and thanks for taking the time to respond..

Regards.. Fred

On 5/1/15 7:22 AM, David McGough wrote:
> Hi Fred,
>
> It appears that still don't have the correct image. The stats are:
>
> root at testserv/RPi2# shasum RPi2_V1.0_Allstar.zip 
> 5498bea63d11de3edd10294d68256005653e8ff6  RPi2_V1.0_Allstar.zip
>
> And the file size is: 540,626,394 bytes
>
> Once unzipped, the binary flash image will be just smaller than 4GB in 
> size.
>
> Typically, the zip container will provide a very high degree of file
> integrity for guarding against download failures, since it internally 
> includes a checksum....What version of unzip are you using?
>
> And, to answer your question about significant security issues, should one 
> occur, we'll release a patched downloadable image, and depending on 
> complexity, perhaps a tarball of replacement binares as well.
>
> Sorry you're having problems,
>
> 73, David KB4FXC
>
>
>
> On Fri, 1 May 2015, Fred Moore wrote:
>
>> Hate to reply to myself.. but I should have included the shasum of the
>> image I was using (downloaded)
>>
>> d1b4d6367d6b2cd7bcaf6ee613d6243da3e1ddd1
>>
>> Regards.. Fred
>>
>> On 5/1/15 3:38 AM, Fred Moore wrote:
>>> Just curious how vulnerabilities are planned for... has a system (other
>>> than) ABS/Packman been thought out or incorporated into this custom Arch
>>> distribution..  if so is app-rpt going to be just a source package in
>>> the future, how is this going to be handled.. I am wondering about
>>> updates..  patches or ???
>>>
>>> For some reason when I dd the image to a 16G class 4 card it took almost
>>> 2 hours.. I was monitoring the process with isotat, it appeared that
>>> some block sequences were transmitted several times each second.. 
>>> anyone else seeing this.. I ran this with two different files with the
>>> same result.. ???  Both file's checksum agreed.
>>>
>>> BTW I tested with Rasbarian image and it finished in about 15 minutes
>>> and didn't seem to be having any problem when monitored with iostat.  I
>>> did veryify the sha of all files I downloaded with each other... 
>>>
>>> Doug if I may be so bold, would you mind publishing the sha checksum's
>>> on the website, so we don't have to download several times and compare
>>> to each other, and are able to verify a 100% correct download..   you
>>> might also think about a code signature.. so we know code that is not
>>> from you, but somehow will get out in the wild.. 
>>>
>>> Thanks for all the hard work... regards.. Fred
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> arm-allstar mailing list
>>> arm-allstar at hamvoip.org
>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>>>
>>> Visit the BBB web page - http://www.crompton.com/hamradio/BeagleBoneBlackAllstar/
>>
>

-- 
Fred Moore
email: fred at fmeco.com
       fred at safes.com
phone:  321-217-8699

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 535 bytes
Desc: OpenPGP digital signature
URL: <http://lists.hamvoip.org/pipermail/arm-allstar/attachments/20150501/0b0cbe42/attachment-0001.pgp>