[arm-allstar] Arch vulnerabilities

Andrew Sylthe asylthe at kc9ona.com
Fri May 1 15:39:38 EST 2015


Fred,

The dd write speed will vary depending on the block size you've chosen.
Try experimenting with different block sizes (64K 128K 256K 512K 1M 2M 4M
8M) to see if your write speed to the SD card increases or decreases.
Personally, I only use Class 10 SD cards.  By design they are faster and
more reliable.

Also, a stat on the file will tell you that Doug used the default 512K
block size when writing the image file, so keep that in mind.

Thanks!

On Fri, May 1, 2015 at 7:12 AM, Fred Moore <fred at fmeco.com> wrote:

> 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
>
>
>
> _______________________________________________
>
> 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/
>



-- 
Andrew Sylthe
KC9ONA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hamvoip.org/pipermail/arm-allstar/attachments/20150501/e6b7fc3e/attachment-0001.html>


More information about the arm-allstar mailing list