Closed
Bug 1297934
(CVE-2016-5272)
Opened 8 years ago
Closed 8 years ago
Bad cast in nsImageGeometryMixin
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
People
(Reporter: inferno, Assigned: tnikkel)
References
Details
(4 keywords, Whiteboard: [adv-main49+][adv-esr45.4+])
Attachments
(2 files)
89 bytes,
text/html
|
Details | |
2.28 KB,
patch
|
mattwoodrow
:
review+
lizzard
:
approval-mozilla-aurora+
lizzard
:
approval-mozilla-beta+
Sylvestre
:
approval-mozilla-esr45+
abillings
:
sec-approval+
|
Details | Diff | Splinter Review |
1. Load testcase and press Tab to trigger.
2. Looks like a bad cast / type confusion issue.
auto lastGeometry =
static_cast<T*>(mozilla::FrameLayerBuilder::GetMostRecentGeometry(aItem));
if (lastGeometry) {
mLastDrawResult = lastGeometry->mLastDrawResult; // crashing here.
==6679==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60b0004e5028 at pc 0x7f0c222bbb93 bp 0x7fffba9ec040 sp 0x7fffba9ec038
READ of size 1 at 0x60b0004e5028 thread T0 (Web Content)
#0 0x7f0c222bbb92 in nsImageGeometryMixin layout/base/nsDisplayListInvalidation.h:101:39
#1 0x7f0c222bbb92 in nsDisplayItemGenericImageGeometry layout/base/nsDisplayListInvalidation.h:163
#2 0x7f0c222bbb92 in nsDisplayRangeFocusRing::AllocateGeometry(nsDisplayListBuilder*) layout/forms/nsRangeFrame.cpp:202
#3 0x7f0c21c3d579 in mozilla::FrameLayerBuilder::ComputeGeometryChangeForItem(mozilla::FrameLayerBuilder::DisplayItemData*) layout/base/FrameLayerBuilder.cpp:4366:22
#4 0x7f0c21c3c5ce in mozilla::FrameLayerBuilder::WillEndTransaction() layout/base/FrameLayerBuilder.cpp:1901:7
#5 0x7f0c21dcbc5f in nsDisplayList::PaintRoot(nsDisplayListBuilder*, nsRenderingContext*, unsigned int) layout/base/nsDisplayList.cpp:1894:17
#6 0x7f0c21e7cd99 in nsLayoutUtils::PaintFrame(nsRenderingContext*, nsIFrame*, nsRegion const&, unsigned int, nsDisplayListBuilderMode, nsLayoutUtils::PaintFrameFlags) layout/base/nsLayoutUtils.cpp:3603:10
#7 0x7f0c21f05989 in PresShell::Paint(nsView*, nsRegion const&, unsigned int) layout/base/nsPresShell.cpp:6640:5
#8 0x7f0c214bda0c in nsViewManager::ProcessPendingUpdatesPaint(nsIWidget*) view/nsViewManager.cpp:484:19
#9 0x7f0c214bc6ae in nsViewManager::ProcessPendingUpdatesForView(nsView*, bool) view/nsViewManager.cpp:415:33
#10 0x7f0c214c051d in nsViewManager::ProcessPendingUpdates() view/nsViewManager.cpp:1118:5
#11 0x7f0c21bf3b99 in nsRefreshDriver::Tick(long, mozilla::TimeStamp) layout/base/nsRefreshDriver.cpp:1898:9
#12 0x7f0c21bfeccd in TickDriver layout/base/nsRefreshDriver.cpp:275:13
#13 0x7f0c21bfeccd in mozilla::RefreshDriverTimer::TickRefreshDrivers(long, mozilla::TimeStamp, nsTArray<RefPtr<nsRefreshDriver> >&) layout/base/nsRefreshDriver.cpp:247
#14 0x7f0c21bfe929 in mozilla::RefreshDriverTimer::Tick(long, mozilla::TimeStamp) layout/base/nsRefreshDriver.cpp:266:5
#15 0x7f0c21c00934 in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::NotifyVsync(mozilla::TimeStamp) layout/base/nsRefreshDriver.cpp:426:9
#16 0x7f0c2259ae74 in mozilla::layout::VsyncChild::RecvNotify(mozilla::TimeStamp const&) layout/ipc/VsyncChild.cpp:64:16
#17 0x7f0c1be65f39 in mozilla::layout::PVsyncChild::OnMessageReceived(IPC::Message const&) objdir-ff-asan/ipc/ipdl/PVsyncChild.cpp:240:20
#18 0x7f0c1b8b1151 in mozilla::ipc::PBackgroundChild::OnMessageReceived(IPC::Message const&) objdir-ff-asan/ipc/ipdl/PBackgroundChild.cpp:2048:28
#19 0x7f0c1b7da134 in mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) ipc/glue/MessageChannel.cpp:1662:25
#20 0x7f0c1b7d68f7 in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) ipc/glue/MessageChannel.cpp:1600:17
#21 0x7f0c1b7c3bff in mozilla::ipc::MessageChannel::OnMaybeDequeueOne() ipc/glue/MessageChannel.cpp:1567:5
#22 0x7f0c1b7f4a62 in applyImpl<mozilla::ipc::MessageChannel, bool (mozilla::ipc::MessageChannel::*)()> objdir-ff-asan/dist/include/nsThreadUtils.h:729:12
#23 0x7f0c1b7f4a62 in apply<mozilla::ipc::MessageChannel, bool (mozilla::ipc::MessageChannel::*)()> objdir-ff-asan/dist/include/nsThreadUtils.h:735
#24 0x7f0c1b7f4a62 in mozilla::detail::RunnableMethodImpl<bool (mozilla::ipc::MessageChannel::*)(), false, true>::Run() objdir-ff-asan/dist/include/nsThreadUtils.h:764
#25 0x7f0c1b7f42ef in Run objdir-ff-asan/dist/include/mozilla/ipc/MessageChannel.h:545:29
#26 0x7f0c1b7f42ef in mozilla::ipc::MessageChannel::DequeueTask::Run() objdir-ff-asan/dist/include/mozilla/ipc/MessageChannel.h:564
#27 0x7f0c1aa15a1e in nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:1058:14
#28 0x7f0c1aa965e8 in NS_ProcessNextEvent(nsIThread*, bool) xpcom/glue/nsThreadUtils.cpp:290:10
#29 0x7f0c1b7e17a1 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp:96:21
#30 0x7f0c1b754ad0 in RunInternal ipc/chromium/src/base/message_loop.cc:232:10
#31 0x7f0c1b754ad0 in RunHandler ipc/chromium/src/base/message_loop.cc:225
#32 0x7f0c1b754ad0 in MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:205
#33 0x7f0c2153565f in nsBaseAppShell::Run() widget/nsBaseAppShell.cpp:156:27
#34 0x7f0c236e7697 in XRE_RunAppShell toolkit/xre/nsEmbedFunctions.cpp:846:22
#35 0x7f0c1b754ad0 in RunInternal ipc/chromium/src/base/message_loop.cc:232:10
#36 0x7f0c1b754ad0 in RunHandler ipc/chromium/src/base/message_loop.cc:225
#37 0x7f0c1b754ad0 in MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:205
#38 0x7f0c236e6d58 in XRE_InitChildProcess toolkit/xre/nsEmbedFunctions.cpp:676:34
#39 0x511ab3 in content_process_main ipc/contentproc/plugin-container.cpp:197:19
#40 0x511ab3 in main browser/app/nsBrowserApp.cpp:369
#41 0x7f0c348e9f44 in __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:287
0x60b0004e5028 is located 0 bytes to the right of 40-byte region [0x60b0004e5000,0x60b0004e5028)
allocated by thread T0 (Web Content) here:
#0 0x4d5cc8 in malloc _asan_rtl_
#1 0x51296d in moz_xmalloc memory/mozalloc/mozalloc.cpp:110:17
#2 0x7f0c21f3009e in operator new objdir-ff-asan/dist/include/mozilla/mozalloc.h:193:12
#3 0x7f0c21f3009e in nsDisplayItem::AllocateGeometry(nsDisplayListBuilder*) layout/base/nsDisplayList.h:1484
#4 0x7f0c21c3d579 in mozilla::FrameLayerBuilder::ComputeGeometryChangeForItem(mozilla::FrameLayerBuilder::DisplayItemData*) layout/base/FrameLayerBuilder.cpp:4366:22
#5 0x7f0c21c3c5ce in mozilla::FrameLayerBuilder::WillEndTransaction() layout/base/FrameLayerBuilder.cpp:1901:7
#6 0x7f0c21dcbc5f in nsDisplayList::PaintRoot(nsDisplayListBuilder*, nsRenderingContext*, unsigned int) layout/base/nsDisplayList.cpp:1894:17
#7 0x7f0c21e7cd99 in nsLayoutUtils::PaintFrame(nsRenderingContext*, nsIFrame*, nsRegion const&, unsigned int, nsDisplayListBuilderMode, nsLayoutUtils::PaintFrameFlags) layout/base/nsLayoutUtils.cpp:3603:10
#8 0x7f0c21f05989 in PresShell::Paint(nsView*, nsRegion const&, unsigned int) layout/base/nsPresShell.cpp:6640:5
#9 0x7f0c214bda0c in nsViewManager::ProcessPendingUpdatesPaint(nsIWidget*) view/nsViewManager.cpp:484:19
#10 0x7f0c214bc6ae in nsViewManager::ProcessPendingUpdatesForView(nsView*, bool) view/nsViewManager.cpp:415:33
#11 0x7f0c214c051d in nsViewManager::ProcessPendingUpdates() view/nsViewManager.cpp:1118:5
#12 0x7f0c21bf3b99 in nsRefreshDriver::Tick(long, mozilla::TimeStamp) layout/base/nsRefreshDriver.cpp:1898:9
#13 0x7f0c21bfeccd in TickDriver layout/base/nsRefreshDriver.cpp:275:13
#14 0x7f0c21bfeccd in mozilla::RefreshDriverTimer::TickRefreshDrivers(long, mozilla::TimeStamp, nsTArray<RefPtr<nsRefreshDriver> >&) layout/base/nsRefreshDriver.cpp:247
#15 0x7f0c21bfe929 in mozilla::RefreshDriverTimer::Tick(long, mozilla::TimeStamp) layout/base/nsRefreshDriver.cpp:266:5
#16 0x7f0c21c00934 in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::NotifyVsync(mozilla::TimeStamp) layout/base/nsRefreshDriver.cpp:426:9
#17 0x7f0c2259ae74 in mozilla::layout::VsyncChild::RecvNotify(mozilla::TimeStamp const&) layout/ipc/VsyncChild.cpp:64:16
#18 0x7f0c1be65f39 in mozilla::layout::PVsyncChild::OnMessageReceived(IPC::Message const&) objdir-ff-asan/ipc/ipdl/PVsyncChild.cpp:240:20
#19 0x7f0c1b8b1151 in mozilla::ipc::PBackgroundChild::OnMessageReceived(IPC::Message const&) objdir-ff-asan/ipc/ipdl/PBackgroundChild.cpp:2048:28
#20 0x7f0c1b7da134 in mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) ipc/glue/MessageChannel.cpp:1662:25
#21 0x7f0c1b7d68f7 in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) ipc/glue/MessageChannel.cpp:1600:17
#22 0x7f0c1b7c3bff in mozilla::ipc::MessageChannel::OnMaybeDequeueOne() ipc/glue/MessageChannel.cpp:1567:5
#23 0x7f0c1b7f4a62 in applyImpl<mozilla::ipc::MessageChannel, bool (mozilla::ipc::MessageChannel::*)()> objdir-ff-asan/dist/include/nsThreadUtils.h:729:12
#24 0x7f0c1b7f4a62 in apply<mozilla::ipc::MessageChannel, bool (mozilla::ipc::MessageChannel::*)()> objdir-ff-asan/dist/include/nsThreadUtils.h:735
#25 0x7f0c1b7f4a62 in mozilla::detail::RunnableMethodImpl<bool (mozilla::ipc::MessageChannel::*)(), false, true>::Run() objdir-ff-asan/dist/include/nsThreadUtils.h:764
#26 0x7f0c1b7f42ef in Run objdir-ff-asan/dist/include/mozilla/ipc/MessageChannel.h:545:29
#27 0x7f0c1b7f42ef in mozilla::ipc::MessageChannel::DequeueTask::Run() objdir-ff-asan/dist/include/mozilla/ipc/MessageChannel.h:564
#28 0x7f0c1aa15a1e in nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:1058:14
#29 0x7f0c1aa965e8 in NS_ProcessNextEvent(nsIThread*, bool) xpcom/glue/nsThreadUtils.cpp:290:10
#30 0x7f0c1b7e17a1 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp:96:21
#31 0x7f0c1b754ad0 in RunInternal ipc/chromium/src/base/message_loop.cc:232:10
#32 0x7f0c1b754ad0 in RunHandler ipc/chromium/src/base/message_loop.cc:225
#33 0x7f0c1b754ad0 in MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:205
#34 0x7f0c2153565f in nsBaseAppShell::Run() widget/nsBaseAppShell.cpp:156:27
#35 0x7f0c236e7697 in XRE_RunAppShell toolkit/xre/nsEmbedFunctions.cpp:846:22
#36 0x7f0c1b754ad0 in RunInternal ipc/chromium/src/base/message_loop.cc:232:10
#37 0x7f0c1b754ad0 in RunHandler ipc/chromium/src/base/message_loop.cc:225
#38 0x7f0c1b754ad0 in MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:205
SUMMARY: AddressSanitizer: heap-buffer-overflow (/mnt/scratch0/clusterfuzz/slave-bot/builds/linux_asan_firefox/custom/firefox/libxul.so+0x9805b92)
Shadow bytes around the buggy address:
0x0c16800949b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fd fd
0x0c16800949c0: fd fd fd fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c16800949d0: fa fa fa fa 00 00 00 00 00 00 fa fa fa fa fa fa
0x0c16800949e0: fa fa fa fa fa fa fa fa fa fa 00 00 00 00 00 fa
0x0c16800949f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c1680094a00: 00 00 00 00 00[fa]fa fa fa fa fa fa fa fa fa fa
0x0c1680094a10: fa fa fa fa fa fa 00 00 00 00 00 fa fa fa fa fa
0x0c1680094a20: fa fa fa fa fa fa fa fa fa fa fa fa fd fd fd fd
0x0c1680094a30: fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c1680094a40: fa fa fd fd fd fd fd fa fa fa fa fa fa fa fa fa
0x0c1680094a50: fa fa fa fa fa fa fa fa fd fd fd fd fd fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==6679==ABORTING
Updated•8 years ago
|
Component: DOM → Layout
Assignee | ||
Comment 1•8 years ago
|
||
I think this is because nsDisplayFocusRing uses display item type TYPE_OUTLINE, which is also used by nsDisplayOutline. Each display item needs it's own type.
This was added in https://hg.mozilla.org/mozilla-central/rev/bb2b0d8fdfd3 from bug 864120, so it was probably just overlooked when implementing the new display item type.
Blocks: 864120
Assignee | ||
Comment 2•8 years ago
|
||
Assignee: nobody → tnikkel
Assignee | ||
Updated•8 years ago
|
Attachment #8785020 -
Flags: review?(matt.woodrow)
Assignee | ||
Comment 3•8 years ago
|
||
I haven't tested that the patch fixes the problem, but I'm guessing it will.
Updated•8 years ago
|
status-firefox48:
--- → wontfix
status-firefox49:
--- → affected
status-firefox50:
--- → affected
status-firefox-esr45:
--- → affected
Assignee | ||
Comment 4•8 years ago
|
||
Getting something automated that checks the invariant that every different display item class gets a different display item type would be good.
Updated•8 years ago
|
Attachment #8785020 -
Flags: review?(matt.woodrow) → review+
Assignee | ||
Comment 5•8 years ago
|
||
Comment on attachment 8785020 [details] [diff] [review]
patch
[Security approval request comment]
How easily could an exploit be constructed based on the patch?
see below
Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
the patch points to <input type="range"> as the source of the issue, knowing that it might not be too hard to run a fuzzer with ASAN builds to find this heap overflow
Which older supported branches are affected by this flaw?
all of them
If not all supported branches, which bug introduced the flaw?
bug 864120
Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
trivial
How likely is this patch to cause regressions; how much testing does it need?
very unlikely, no extra testing required
Attachment #8785020 -
Flags: sec-approval?
Comment 6•8 years ago
|
||
sec-approval+ for trunk. Please nominate aurora, beta, and ESR45 patches as we're running out of time.
Release Management, this is a TWO line change so it should be pretty safe everywhere.
tracking-firefox49:
--- → +
tracking-firefox50:
--- → +
tracking-firefox51:
--- → +
tracking-firefox-esr45:
--- → 49+
Updated•8 years ago
|
Attachment #8785020 -
Flags: sec-approval? → sec-approval+
Assignee | ||
Comment 7•8 years ago
|
||
Assignee | ||
Comment 8•8 years ago
|
||
Comment on attachment 8785020 [details] [diff] [review]
patch
[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: hasn't been rated yet, but heap overflows are usually sec-crit
User impact if declined: security issue
Fix Landed on Version: 51
Risk to taking this patch (and alternatives if risky): safe
String or UUID changes made by this patch: none
See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
Approval Request Comment
[Feature/regressing bug #]: bug 864120
[User impact if declined]: security issue
[Describe test coverage new/current, TreeHerder]: none
[Risks and why]: safe
[String/UUID change made/needed]: none
Attachment #8785020 -
Flags: approval-mozilla-esr45?
Attachment #8785020 -
Flags: approval-mozilla-beta?
Attachment #8785020 -
Flags: approval-mozilla-aurora?
Comment 9•8 years ago
|
||
No security rating here. Dan can you help out?
tnikkel can you request sec-approval, assuming this may turn out to be sec-critical?
We will likely go to build Monday morning, so if this misses beta 8 we can still consider it for beta 9 later in the week.
Flags: needinfo?(tnikkel)
Flags: needinfo?(dveditz)
Assignee | ||
Comment 10•8 years ago
|
||
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #9)
> tnikkel can you request sec-approval, assuming this may turn out to be
> sec-critical?
sec-approval has already been requested and granted, see comment 6.
Flags: needinfo?(tnikkel)
Assignee | ||
Comment 11•8 years ago
|
||
Would you mind confirming that the patch fixed the issue for you?
Flags: needinfo?(inferno)
Reporter | ||
Comment 12•8 years ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #11)
> Would you mind confirming that the patch fixed the issue for you?
Verified that the patch fixes the bad cast.
Flags: needinfo?(inferno)
Comment 13•8 years ago
|
||
I missed that. Thanks.
Comment 14•8 years ago
|
||
Comment on attachment 8785020 [details] [diff] [review]
patch
Likely sec-critical, fix verified in comment 12, let's uplift this for the beta 8 build.
Attachment #8785020 -
Flags: approval-mozilla-beta?
Attachment #8785020 -
Flags: approval-mozilla-beta+
Attachment #8785020 -
Flags: approval-mozilla-aurora?
Attachment #8785020 -
Flags: approval-mozilla-aurora+
Updated•8 years ago
|
Keywords: sec-critical
Comment 15•8 years ago
|
||
Comment on attachment 8785020 [details] [diff] [review]
patch
Taking to esr45 too.
Attachment #8785020 -
Flags: approval-mozilla-esr45? → approval-mozilla-esr45+
Comment 16•8 years ago
|
||
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(dveditz) → in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Updated•8 years ago
|
Flags: sec-bounty?
Updated•8 years ago
|
Group: core-security → core-security-release
Updated•8 years ago
|
Flags: qe-verify+
Updated•8 years ago
|
Whiteboard: [adv-main49+][adv-esr45.4+]
Comment 18•8 years ago
|
||
Reproduced on 50.0a1 (2016-06-15) asan build, Ubuntu 14.04.
Verified fixed FX 49.0, 50.0a2 (2016-09-07), 45.4.0 ESR asan builds.
Any idea why there are no recent asan builds on http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-linux64-asan/ ?
Flags: needinfo?(tnikkel)
Assignee | ||
Comment 19•8 years ago
|
||
(In reply to Paul Silaghi, QA [:pauly] from comment #18)
> Any idea why there are no recent asan builds on
> http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-
> linux64-asan/ ?
That's a question for someone else, but I'm not sure who would know.
Flags: needinfo?(tnikkel)
Comment 20•8 years ago
|
||
(In reply to Paul Silaghi, QA [:pauly] from comment #18)
> Any idea why there are no recent asan builds on
> http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-
> linux64-asan/ ?
Those builds aren't made by Tinderbox anymore. They moved to Task Cluster by release engineering (don't ask me why). My team documented how to get current builds:
Manual browsing:
1. Go to
https://tools.taskcluster.net/index/artifacts/#gecko.v2.mozilla-central.latest.firefox/gecko.v2.mozilla-central.latest.firefox.linux64-asan-opt
2. On the right side, you will see the most recent build (the browser is
in "public/build/target.tar.bz2").
Automated downloading:
There is a JSON API for accessing the index and the artifacts of a task,
so you would have to:
1. Fetch
https://index.taskcluster.net/v1/task/gecko.v2.mozilla-central.latest.firefox.linux64-asan-opt
2. Extract the taskId from the response.
3. Fetch https://queue.taskcluster.net/v1/task/<TASKID>/artifacts
(replace <TASKID> with the id from the previous response).
4. Extract list of desired files and fetch them by appending them to the
previous URL, e.g. the browser will be at:
https://queue.taskcluster.net/v1/task/<TASKID>/artifacts/public/build/target.tar.bz2
Comment hidden (obsolete) |
Updated•8 years ago
|
Alias: CVE-2016-5272
Comment 22•8 years ago
|
||
Thanks for clarifying.
Verified fixed FX 51.0a1 (2016-09-08) asan, Ubuntu 14.04.
Status: RESOLVED → VERIFIED
Comment 23•8 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #21)
> From talking to catlee, I think the answer is:
> https://tools.taskcluster.net/index/#gecko.v2.mozilla-central.pushdate/
> gecko.v2.mozilla-central.pushdate
How do I download a build from there?
Let's say: https://tools.taskcluster.net/index/#gecko.v2.mozilla-central.pushdate.2016.09.01.20160901001112.firefox/gecko.v2.mozilla-central.pushdate.2016.09.01.20160901001112.firefox.linux64-asan-opt
Flags: needinfo?(dholbert)
Comment 24•8 years ago
|
||
Currently you'd need to jump through 3 more hoops from that page (yes, this sucks):
- Click the "TaskId" link
- Click "Run 0"
- Under "Artifacts", click "public/build/target.tar.bz2"
That'll give you the firefox build.
(catlee says that these extra hoops are arguably a bug in taskcluster, and I've brought it up in #taskcluster. Hopefully the URL from comment 23 will just have an easy link to the build, at some point in the future.)
Flags: needinfo?(dholbert)
Comment 25•8 years ago
|
||
OK, better steps: use the "artifact" view on taskcluster, which has a similar folder structure to my link in comment 21, but actually shows you download links on the right.
You can start navigating (by year, month, etc) from here:
https://tools.taskcluster.net/index/artifacts/#gecko.v2.mozilla-central.pushdate/gecko.v2.mozilla-central.pushdate
...and you'll end up at a page like this:
https://tools.taskcluster.net/index/artifacts/#gecko.v2.mozilla-central.pushdate.2016.09.01.20160901001112.firefox/gecko.v2.mozilla-central.pushdate.2016.09.01.20160901001112.firefox.linux64-asan-opt
...and target.tar.bz2 (linked on the right) is the file you're looking for.
Comment 26•8 years ago
|
||
If you are just looking for the latest build, there is an easy way. Just use this direct URL for downloading:
https://index.taskcluster.net/v1/task/gecko.v2.mozilla-central.latest.firefox.linux64-asan-opt/artifacts/public/build/target.tar.bz2
Comment 27•8 years ago
|
||
(Yup, abillings already gave a version of that link, in comment 20.)
Comment 28•8 years ago
|
||
Thank you for your explanations!
Updated•8 years ago
|
Flags: sec-bounty? → sec-bounty+
Updated•8 years ago
|
Group: core-security-release
Updated•8 months ago
|
Keywords: reporter-external
You need to log in
before you can comment on or make changes to this bug.
Description
•