[arm-allstar] Arch vulnerabilities
Fred Moore
fred at fmeco.com
Fri May 1 16:47:51 EST 2015
I totally understand.. the fact that the first utility I chose was
iostat should tell you I understand all of this.. only been doing this
since 1978.. I will get to the bottom of my issue.. I am running, I
was just investigation the write speed issue.. I am actually sorry I
posted this to the list... way too much noise about this already..
Andrew, I hate to break the bad news to you but the "stat" command shows
the blocking factor of the "block device" the file is currently stored
on, not the block size of where he originally built and stored the
file.. yours might be 512, but mine is not...
Thanks for the assist.. guys.. I can handle it from here.. Fred
On 5/1/15 4:39 PM, Andrew Sylthe wrote:
> 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
> <mailto: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 <mailto: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 <mailto:fred at fmeco.com>
> fred at safes.com <mailto:fred at safes.com>
> phone: 321-217-8699 <tel:321-217-8699>
>
>
>
> _______________________________________________
>
> arm-allstar mailing list
> arm-allstar at hamvoip.org <mailto: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
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
--
Fred Moore
email: fred at fmeco.com
fred at safes.com
phone: 321-217-8699
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hamvoip.org/pipermail/arm-allstar/attachments/20150501/8068b8eb/attachment-0001.html>
-------------- 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/8068b8eb/attachment-0001.pgp>
More information about the arm-allstar
mailing list