Open Bug 1274632 Opened 6 years ago Updated 10 months ago

SeaMonkey's bouncer links go to http://download.cdn.mozilla.net

Categories

(SeaMonkey :: Release Engineering, defect)

Unspecified
All
defect
Not set
major

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: RainerBielefeldNG, Assigned: ewong)

References

()

Details

Attachments

(1 file)

... instead of   http://download.cdn.mozilla.net/ 

For Details see Bug 1272909 comment#10 h)
a) this issue affects download of all latest release installers, but not
   downloads from https://archive.mozilla.org/pub/...
See Also: → 1275335
Hey there. I've just told a group of activists to start using SeaMonkey (which I read about and want to start using myself because of issues with Thunderbird) ...and I look like a complete fool right now. 

I can't download the application because it says the connection is untrusted! But it's download.cdn.mozilla.net! Can someone help me? Am I following the right bug here and how do I get HELP. I want to support what you-all do, but this is making me look really bad.

When I click your link from this post, I just get a blank dir of files I don't understand. Here a copy of the (unbelievably ironic) error:

Your connection is not secure

The owner of download.cdn.mozilla.net has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website.

This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox only connect to it securely. As a result, it is not possible to add an exception for this certificate.

Learn more…
NEW due to <https://blog.seamonkey-project.org/2015/11/25/my-unconfirmed-bug-reports/>

@Sean:
For support requests please follow advice here <http://www.seamonkey-project.org/community>, this bug tracker is the wrong place.

We know the problem what appeared after some changes with the web page if you use NoScript. 

As an unsatisfactory workaround you have to replace "download" by "download-installer", and everything will work fine. Or to follow advice in Bug 1272909 comment #11 and Bug 1272909 comment #10
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
I am not quite sure what's going on.  As far as I know on the website,
we don't have download links that specify download*.cdn.mozilla.net.

However, it seems that if you do click on the downloads,  it gets
the files from download.cdn.mozilla.net, which is http.  According
to bug 1276848 (and bug 1272909), , NoScript is forcing 
http://download.cdn.mozilla.net to use SSL.

I'm looking at bug 1228502, and I'm wondering if this the way to go.
Component: www.seamonkey-project.org → Operations: Product Delivery
Product: Websites → Cloud Services
QA Contact: oremj
Summary: For SeaMonkey download use https://download-installer.cdn.mozilla.net/ → SeaMonkey's bouncer links go to download.cdn.mozilla.net
Version: Trunk → unspecified
Related to bug 1257214
Summary: SeaMonkey's bouncer links go to download.cdn.mozilla.net → SeaMonkey's bouncer links go to http://download.cdn.mozilla.net
If the build should be served via SSL, the build needs to be marked as SSL only in bouncer. download.cdn.mozilla.net is HTTP only.
(In reply to Jeremy Orem [:oremj] from comment #6)
> If the build should be served via SSL, the build needs to be marked as SSL
> only in bouncer. download.cdn.mozilla.net is HTTP only.

Thanks for the clarification.

:Callek, should our builds be marked SSL in the future?
Flags: needinfo?(bugspam.Callek)
Duplicate of this bug: 1321080
On deeper thought, I think it would be appropriate to mark it SSL in the future.
Blocks: SM2.46
FWIW, I think you should move this to a SeaMonkey component.

To fix this you'd need to set
  post_data['ssl_only'] = "true"
before line 171 in product_add(), see https://hg.mozilla.org/build/tools/file/default/release/tuxedo-add.py#l161. I suggest adding a new argument 'ssl' that defaults to False. Pass a value of True in add_products() at line 187, near https://hg.mozilla.org/build/tools/file/default/release/tuxedo-add.py#l186, so that the installers are served via SSL. The updates can continue to be served via http because they're protected by hashes.

AFAICT only SeaMonkey is using tuxedo-add.py.
Flags: needinfo?(bugspam.Callek)
(In reply to Nick Thomas [:nthomas] from comment #10)
> FWIW, I think you should move this to a SeaMonkey component.

Thanks.. Will do.. though I'll need to modify build/tools file.

> 
> To fix this you'd need to set
>   post_data['ssl_only'] = "true"
> before line 171 in product_add(), see
> https://hg.mozilla.org/build/tools/file/default/release/tuxedo-add.py#l161.
> I suggest adding a new argument 'ssl' that defaults to False. Pass a value
> of True in add_products() at line 187, near
> https://hg.mozilla.org/build/tools/file/default/release/tuxedo-add.py#l186,
> so that the installers are served via SSL. The updates can continue to be
> served via http because they're protected by hashes.
> 
> AFAICT only SeaMonkey is using tuxedo-add.py.

Ah. I didn't know that.
Component: Operations: Product Delivery → Release Engineering
Product: Cloud Services → SeaMonkey
QA Contact: oremj
Assignee: nobody → ewong
Status: NEW → ASSIGNED
Attachment #8820175 - Flags: review?(nthomas)
Comment on attachment 8820175 [details] [diff] [review]
[moco-tools] use ssl only

I'd rather not change updates to ssl too, unless there is some justification that applies to SeaMonkey specifically.
Attachment #8820175 - Flags: review?(nthomas)
Unsetting 2.46 block, since this needs a bit of figuring out.
No longer blocks: SM2.46
You need to log in before you can comment on or make changes to this bug.