I'm partly just guessing here but I think It's almost certainly my fault.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 15 2015
Nov 14 2015
Thanks, I spent ~10 minutes on it but couldn't figure it out.
File should be getting attached to the paste, but isn't. I think I accidentally caused a side effect here when changing how the transaction works.
Actually something weird is going on... I can't edit pastes either, even if the Edit Policy is set to "All Users".
I'm not sure how to fix this without adding pastePHID to PhabricatorFile, which doesn't feel like the best approach.
I started looking at this. It seems like the file attached to the Paste has a view policy of no-one, whereas it should probably inherit the view policy of the parent Paste.
Nov 13 2015
In the general case, this is impossible to resolve. Suppose that you had conflicting linter rules, such as one whiche enforced that files end with a newline character and another which enforces that files do not end with a newline character.
MySQL version is 5.6.27-0ubuntu1.
> time ./bin/storage upgrade --namespace testT9773 --force --no-adjust Loading quickstart template... Applying patch 'phabricator:db.xhpast'... Applying patch 'phabricator:20150906.mailinglist.sql'... Applying patch 'phabricator:20150930.drydock.log.1.sql'... Applying patch 'phabricator:20151001.drydock.rname.1.sql'... Applying patch 'phabricator:20151002.dashboard.status.1.sql'... Applying patch 'phabricator:20151002.harbormaster.bparam.1.sql'... Applying patch 'phabricator:20151009.drydock.auth.1.sql'... Applying patch 'phabricator:20151010.drydock.auth.2.sql'... Applying patch 'phabricator:20151013.drydock.op.1.sql'... Applying patch 'phabricator:20151023.harborpolicy.1.sql'... Applying patch 'phabricator:20151023.harborpolicy.2.php'... Applying patch 'phabricator:20151023.patchduration.sql'... Applying patch 'phabricator:20151030.harbormaster.initiator.sql'... Applying patch 'phabricator:20151106.editengine.1.table.sql'... Applying patch 'phabricator:20151106.editengine.2.xactions.sql'... Applying patch 'phabricator:20151106.phame.post.mailkey.1.sql'... Applying patch 'phabricator:20151106.phame.post.mailkey.2.php'... Applying patch 'phabricator:20151107.phame.blog.mailkey.1.sql'... Applying patch 'phabricator:20151107.phame.blog.mailkey.2.php'... Applying patch 'phabricator:20151108.phame.blog.joinpolicy.sql'... Applying patch 'phabricator:20151108.xhpast.stderr.sql'... Applying patch 'phabricator:20151109.phame.post.comments.1.sql'... Applying patch 'phabricator:20151109.repository.coverage.1.sql'... Applying patch 'phabricator:20151109.xhpast.db.1.sql'... Applying patch 'phabricator:20151109.xhpast.db.2.sql'... Applying patch 'phabricator:20151110.daemonenvhash.sql'... Storage is up to date. Use 'storage status' for details. Declining to apply storage adjustments.
This is the only thing that is blocking me from migrating all of our repositories from Gitlab to Phabricator. Is there a clear path forward here? If so, I could potentially work on this.
(HTTP over public wireless has those properties, but using MFA and not using HTTPS is silly and the lack of HTTPS is a far greater problem than the larger MFA vulnerability window.)
could MITM the connection between the verifier and prover
There are some attacks that could be performed on such MFA schemes but that are not applicable in phabricator's security model.
I think the RFC should be followed.
I can't reproduce this either, nor does it reproduce on this install.
I'd like to understand the reason behind this before moving forward.
I don't want to introduce this level of complexity into Herald.
One thing I noticed is that I have a large number of test databases locally.
Here is a profile from running ManiphestTaskTestCase only (and without coverage): https://secure.phabricator.com/xhprof/profile/PHID-FILE-fkx2c4q3wtfn6cetww6s/
See https://secure.phabricator.com/xhprof/profile/PHID-FILE-jfpnkcj4lvtjwojxmttl/, which shows the profile from running arc unit --everything.
Right, I see. I had darkconsole.always-on enabled.
I'm not concern ed from a security point of view... I'd just rather not give people functionality that they don't need. Specifically, I'm sure someone will open DarkConsole by mistake and not know how to close it.
In T7053#144095, @epriestley wrote:This also seems to work properly on this host, although I hit the "daemons are not running" setup warning once, presumably by racing their restart. If this is an issue we can tweak how that warning works, I think.
Nov 12 2015
Running on a local MySQL server... I'll try to profile the tests later.
In T9766#144249, @eadler wrote:A somewhat generic way to do this is to create the notion of a variable such as is_in_deployment and allow Herald rules to check to see if this is set/true/a specific value. If the API to expose the variable is exposed to conduit then also allows for far more interesting workflows (especially when combined with relying on other Herald rules).
Is there a specific security purpose behind this? That is, what attack is this measure aimed at defusing?
Nov 11 2015
In T9767#144214, @chad wrote:Maybe add a "View Options" button to "File Contents" in Diffusion? That seems most consistent.
Oh, right... it's not explicit in Differential. But rather when the file is too large for syntax highlighting.
Hmm, why not? I'd prefer it (and it would be more consistent) if it wasn't editable, as in Differential.
Just to clarify, you would rather rely on an external script to activate and deactivate this rule every day instead of having a Herald condition like "Current time is between 5PM and 9AM"?
I don't plan to support this in the upstream. This configuration is inherently dangerous because the custom application has access to Phabricator's cookies, and not one we recommend.
Ah OK, good to know.
You should be able to batch edit infinite tasks.
How exactly are you embedding it?
In T7053#144090, @epriestley wrote:
- When editing the small amount of config which can't auto-restart (phd.user, phd.start-taskmasters). I think phd.user already has an existing warning anyway.
Yeah, I would like to handle this properly but I'm not sure if it is worthwhile doing so?
In T3670#144082, @epriestley wrote:This is currently difficult to do because it involves bulk editing our entire workboard
What's difficult about this? Can't you just use the bulk editor to "Remove project X" and "Add project Y"?
In T9759#144069, @epriestley wrote:We don't show a specific amount of history: we show all activity since your last activity.
Nov 10 2015
In T9760#144113, @epriestley wrote:Right, Almanac does not support autoscaling.
Right, Almanac does not support autoscaling. We'll have an EC2 blueprint (and similar) in the future which can manage autoscaling more simply. Almanac is the ground level "I have a list of IPs" version of things.
bin/almanac register is just a shortcut for "put the private half of a key in the right place on disk, and the public half on the specified Almanac device". Maybe a clearer name would be bin/almanac install-keys.
Right okay, but I can't autoscale the Drydock Pool right? Because I need to manually create new devices through the UI.
This just means adding a device interface?
In T9760#144107, @epriestley wrote:
- Bind it to your pool to actually put it in service.
So what does ./bin/almanac register actually do?
Right. You just need to:
Ok thanks. So I don't need to register my build agent with ./bin/almanac register?
Don't do steps (3) or (4)! Those are useless at best, and dangerous at worst.
- The view page doesn't actually show the short URL anywhere. You can copy it from "View URL", but I think this isn't totally obvious, and we probably have enough room to reasonably add it (e.g., "Short URL: ..." under "Original URL: ...").
- If a link has an alias, "View URL" still links to the non-alias version (e.g. U6 links to /u/6, but a more-preferred link would be /u/bug).
- The "Remarkup Reference" document (https://secure.phabricator.com/book/phabricator/article/remarkup/) should explain how to use ((6)) and ((bug)). It might be worthwhile to hint these on the U6 page itself, e.g. In Remarkup: ((bug)) in the properties? Not sure how useful/cluttered that would look.
- Maybe show aliases on the list at /phurl/?
- Maybe let users search for the link with a particular alias? If I know ((bug)), there's no way for me to actually find the URL object right now. Hovercards would be one fix but just going to Phurl and being able to search for "Alias: bug" is probably good too.
This also seems to work properly on this host, although I hit the "daemons are not running" setup warning once, presumably by racing their restart. If this is an issue we can tweak how that warning works, I think.
Oh, transaction publishing from Phurl also currently fails in the daemons:
One possible minor followup to maybe keep on the radar is showing some extra warnings in a few cases:
A couple of notes so far, after poking at this:
The resolution of T7053 should indirectly resolve this.
This is currently difficult to do because it involves bulk editing our entire workboard
I have a use case which is maybe suited for subprojects, but I don't exactly know how you are planning on implementing this...
We run this entire algorithm ourselves and it's pretty simple (basically just looks at indent levels, no language awareness). Should be pretty easy to have it peek at the previous line if it initially finds a line containing only "{" and see if that line is at the same indent level and otherwise suitable.