Points to a private site listed as a security risk. http://luke.dashjr.org
bman also gave me this link https://www.cryptocoinsnews.com/bitcoin-address-blacklists-found-gentoo-linux/ I can't help but wonder if this isn't because of all the political stuff surrounding the ljr patch. How does a site get blacklisted? What is it distributing that's so bad? Is the ljr patch considered malware?!?! I don't know but if this is a 3rd round of political upheavals regarding bitcoin then I'm just dropping proxying of the packages.
I have more analysis to complete regarding this, but considering the potential implications, we ought to mask. It may be a false positive at this point, but the intent to host self served patches has my concern. Especially regarding the previous reports.
(In reply to Aaron Bauman from comment #2) > I have more analysis to complete regarding this, but considering the > potential implications, we ought to mask. It may be a false positive at > this point, but the intent to host self served patches has my concern. > Especially regarding the previous reports. Why mask? We just drop the patch ljr patch. grep the eclass and net-p2p/bitcoin*/bitcoin*ebuild for LJR and remove.
Why not drop the eclass altogether and get the ebuilds back to sanity?
(In reply to David Abbott from comment #0) > Points to a private site listed as a security risk. > http://luke.dashjr.org Unless you can point to technical data supporting this, it's essentially censorship by a random third party, so I would be very careful here. Now, if you can find the reason for the listing, that's different...
https://productforums.google.com/forum/#!topic/webmasters/wp9EuO4vFUs;context-place=topicsearchin/webmasters/authorid$3AAPn2wQfLXw8SQCBlTibhIgaNeQGiUeo3QJUJtBokaRU6z3ZM5Xb1n1uam1l8ocw-FETYOHc4PE1S%7Csort:date%7Cspell:false ^ This is a 2-year old post on Google Webmaster Central that *might* be related.
https://www.google.com/transparencyreport/safebrowsing/diagnostic/index.html#url=http://luke.dashjr.org ^ This is helpful, but it took some time to find it.
The patches should be hashed so it isn't like anybody can tamper with them (if they aren't hashed, then the package should be masked simply for that, which is why live scm ebuilds aren't allowed to be unmasked). I'd suggest stating the concern in terms of something this site actually does, and not simply the fact that Google flags it. It sounds like there is an antivirus false positive on the site, because it hosts mining software. I get that mining software is associated with some malware that, well, mines. But, banning for hosting the software itself without any kinds of exploits/etc seems like a false positive.
(In reply to Richard Freeman from comment #8) > The patches should be hashed so it isn't like anybody can tamper with them > (if they aren't hashed, then the package should be masked simply for that, > which is why live scm ebuilds aren't allowed to be unmasked). > > I'd suggest stating the concern in terms of something this site actually > does, and not simply the fact that Google flags it. It sounds like there is > an antivirus false positive on the site, because it hosts mining software. > I get that mining software is associated with some malware that, well, > mines. But, banning for hosting the software itself without any kinds of > exploits/etc seems like a false positive. Luke can house the ljr patch elsewhere (like github) and that will at least solve our immediate problem.
luke.dashjr.org is not a security risk, so not-a-bug/invalid.
More details: At least in Google's case, it seems to be censorship of Bitcoin mining software, which I also develop. There is no apparent avenue to even ask Google to reconsider (they have an automated "review" that does not seem to ever see human eyes or work in any useful way). Norton recently picked BFGMiner up automatically also, but after a review was requested, confirmed their detection was a false positive and now considers the site clean: https://safeweb.norton.com/report/show?url=luke.dashjr.org
Also, FWIW, the patches for 0.12 are available from http://bitcoinknots.org/files/0.12.x/0.12.1.knots20160629/test/rc2/bitcoin-0.12.1.knots20160629.rc2.patches.txz However, AFAIK, none of Portage's fetching tools care in the slightest about Google's slander - so I'm not sure the point in changing the URI used here.
(In reply to Anthony Basile from comment #3) > (In reply to Aaron Bauman from comment #2) > > I have more analysis to complete regarding this, but considering the > > potential implications, we ought to mask. It may be a false positive at > > this point, but the intent to host self served patches has my concern. > > Especially regarding the previous reports. > > Why mask? We just drop the patch ljr patch. grep the eclass and > net-p2p/bitcoin*/bitcoin*ebuild for LJR and remove. Even better.
(In reply to Aaron Bauman from comment #13) > (In reply to Anthony Basile from comment #3) > > (In reply to Aaron Bauman from comment #2) > > > I have more analysis to complete regarding this, but considering the > > > potential implications, we ought to mask. It may be a false positive at > > > this point, but the intent to host self served patches has my concern. > > > Especially regarding the previous reports. > > > > Why mask? We just drop the patch ljr patch. grep the eclass and > > net-p2p/bitcoin*/bitcoin*ebuild for LJR and remove. > > Even better. My understanding is that this is an optional patch that a user has to explicitly enable, and there isn't actually anything wrong with it from a security standpoint. I don't get why it should be dropped.
(In reply to Richard Freeman from comment #14) > (In reply to Aaron Bauman from comment #13) > > (In reply to Anthony Basile from comment #3) > > > (In reply to Aaron Bauman from comment #2) > > > > I have more analysis to complete regarding this, but considering the > > > > potential implications, we ought to mask. It may be a false positive at > > > > this point, but the intent to host self served patches has my concern. > > > > Especially regarding the previous reports. > > > > > > Why mask? We just drop the patch ljr patch. grep the eclass and > > > net-p2p/bitcoin*/bitcoin*ebuild for LJR and remove. > > > > Even better. > > My understanding is that this is an optional patch that a user has to > explicitly enable, and there isn't actually anything wrong with it from a > security standpoint. > > I don't get why it should be dropped. I was just acking his approach if we did have to. This looks like true censorship to me as well. Norton just the other day had the site listed as a potential hazard. If no one is concerned that the patches are not hosted on Gentoo infrastructure and it is not a violation of policy then I think this issue is solved.
(In reply to Aaron Bauman from comment #15) > If no one is concerned that the patches are not hosted on Gentoo > infrastructure and it is not a violation of policy then I think this issue > is solved. AFAIK they're mirrored on Gentoo infra like any other distfile. Not sure why it would be expected any different for this case either.
(In reply to Richard Freeman from comment #14) > > I don't get why it should be dropped. When I said that I thought it was the cause of the blacklisting. It isn't, its the windows dll's. So no need to drop. (In reply to Luke-Jr from comment #16) > (In reply to Aaron Bauman from comment #15) > > If no one is concerned that the patches are not hosted on Gentoo > > infrastructure and it is not a violation of policy then I think this issue > > is solved. > > AFAIK they're mirrored on Gentoo infra like any other distfile. Not sure why > it would be expected any different for this case either. There's no problem here, it was a false positive. IMO this issue is solve.d
(In reply to Anthony Basile from comment #17) > (In reply to Richard Freeman from comment #14) > > > > I don't get why it should be dropped. > > When I said that I thought it was the cause of the blacklisting. It isn't, > its the windows dll's. So no need to drop. > Curious, what led you to that conclusion? I have been looking for the "why" in the various companies listings. > (In reply to Luke-Jr from comment #16) > > (In reply to Aaron Bauman from comment #15) > > > If no one is concerned that the patches are not hosted on Gentoo > > > infrastructure and it is not a violation of policy then I think this issue > > > is solved. > > > > AFAIK they're mirrored on Gentoo infra like any other distfile. Not sure why > > it would be expected any different for this case either. > > There's no problem here, it was a false positive. IMO this issue is solve.d Anyone else have concerns regarding this?
(In reply to Aaron Bauman from comment #18) > > Curious, what led you to that conclusion? I have been looking for the "why" > in the various companies listings. It is due to bfgminer-3.10.0-win32.zip https://www.virustotal.com/en/file/793302e10e65cf97fe41ea23f5ad7f1a4cd5e87589f3b14f49b24536ff36edd8/analysis/1397943645/
I'd blame incompetence and complacency over censorship here. A lot of malware installs mining software to make a few bucks. So mining software becomes an easy target for scanners, since few people use it legitimately. Sure, it is dumb, just like blocking connections from non-exit tor relays, but big companies love to do stuff like this. They don't care about blocking a bit of innocent use if it blocks a lot of stuff that causes them work.
(In reply to Richard Freeman from comment #20) > I'd blame incompetence and complacency over censorship here. > yeah that's my reading of it.
