[jira] [Commented] (ACCUMULO-4688) Consider adding autocomplete=false to the shell servlet's password input element
[
https://issues.apache.org/jira/browse/ACCUMULO-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110093#comment-16110093
]
Josh Elser commented on ACCUMULO-4688:
--
bq. So, since I'm a strong -1, how about we leave this open for comment for
another 24 hours (or longer if you think better)
This was essentially my plan. Whenever I circle around to this next after 24hrs
or so, I'd just close as "Won't Fix".
> Consider adding autocomplete=false to the shell servlet's password input
> element
>
>
> Key: ACCUMULO-4688
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4688
> Project: Accumulo
> Issue Type: Improvement
> Components: monitor
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: 1.7.4, 1.8.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Had a report from a user which identified an 'issue" in the ShellServlet
> around the password input element.
> There is an attribute {{autocomplete}} which can be set to false on the
> {{input}} element that will instruct browsers to not try to save the password
> in some store. In theory, this marginally improves security as the password
> would not be stored on the local machine in (potentially) some way that could
> be accessed by an adversary.
> I'm on the fence about the value of making this change (if the browser
> doesn't do this automatically, users would probably do this on their own in a
> way that is *less* secure than how the browser could). Thoughts from everyone
> else?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
Accumulo-1.7 - Build # 368 - Failure
The Apache Jenkins build system has built Accumulo-1.7 (build #368) Status: Failure Check console output at https://builds.apache.org/job/Accumulo-1.7/368/ to view the results.
Accumulo-Master - Build # 2131 - Failure
The Apache Jenkins build system has built Accumulo-Master (build #2131) Status: Failure Check console output at https://builds.apache.org/job/Accumulo-Master/2131/ to view the results.
[jira] [Commented] (ACCUMULO-4688) Consider adding autocomplete=false to the shell servlet's password input element
[
https://issues.apache.org/jira/browse/ACCUMULO-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110049#comment-16110049
]
Christopher Tubbs commented on ACCUMULO-4688:
-
So, since I'm a strong -1, how about we leave this open for comment for another
24 hours (or longer if you think better), and if nothing changes, we drop as
"Not A Problem"?
> Consider adding autocomplete=false to the shell servlet's password input
> element
>
>
> Key: ACCUMULO-4688
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4688
> Project: Accumulo
> Issue Type: Improvement
> Components: monitor
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: 1.7.4, 1.8.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Had a report from a user which identified an 'issue" in the ShellServlet
> around the password input element.
> There is an attribute {{autocomplete}} which can be set to false on the
> {{input}} element that will instruct browsers to not try to save the password
> in some store. In theory, this marginally improves security as the password
> would not be stored on the local machine in (potentially) some way that could
> be accessed by an adversary.
> I'm on the fence about the value of making this change (if the browser
> doesn't do this automatically, users would probably do this on their own in a
> way that is *less* secure than how the browser could). Thoughts from everyone
> else?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ACCUMULO-3827) Default store types for monitor SSL are broken
[ https://issues.apache.org/jira/browse/ACCUMULO-3827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110039#comment-16110039 ] Christopher Tubbs commented on ACCUMULO-3827: - I updated the fixVersion from 1.7.1 to 1.7.4, since the commit you cherry-picked mentions this issue, and I didn't want things to be confusing. :) > Default store types for monitor SSL are broken > -- > > Key: ACCUMULO-3827 > URL: https://issues.apache.org/jira/browse/ACCUMULO-3827 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: Billie Rinaldi >Assignee: Billie Rinaldi > Fix For: 1.7.4, 1.8.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Not sure why I left the default types an empty string, because that doesn't > actually work. They should be "jks". A workaround for 1.7.0 is to set the > monitor.ssl.keyStoreType and monitor.ssl.trustStoreType properties explicitly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ACCUMULO-3827) Default store types for monitor SSL are broken
[ https://issues.apache.org/jira/browse/ACCUMULO-3827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs updated ACCUMULO-3827: Fix Version/s: (was: 1.7.1) > Default store types for monitor SSL are broken > -- > > Key: ACCUMULO-3827 > URL: https://issues.apache.org/jira/browse/ACCUMULO-3827 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: Billie Rinaldi >Assignee: Billie Rinaldi > Fix For: 1.7.4, 1.8.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Not sure why I left the default types an empty string, because that doesn't > actually work. They should be "jks". A workaround for 1.7.0 is to set the > monitor.ssl.keyStoreType and monitor.ssl.trustStoreType properties explicitly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ACCUMULO-3827) Default store types for monitor SSL are broken
[ https://issues.apache.org/jira/browse/ACCUMULO-3827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs updated ACCUMULO-3827: Fix Version/s: 1.7.4 > Default store types for monitor SSL are broken > -- > > Key: ACCUMULO-3827 > URL: https://issues.apache.org/jira/browse/ACCUMULO-3827 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: Billie Rinaldi >Assignee: Billie Rinaldi > Fix For: 1.7.1, 1.7.4, 1.8.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Not sure why I left the default types an empty string, because that doesn't > actually work. They should be "jks". A workaround for 1.7.0 is to set the > monitor.ssl.keyStoreType and monitor.ssl.trustStoreType properties explicitly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (ACCUMULO-3283) MetadataTableUtil.getTabletEntries creates ColumnFQ twice unnecessarily
[
https://issues.apache.org/jira/browse/ACCUMULO-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Tubbs resolved ACCUMULO-3283.
-
Resolution: Fixed
Assignee: Daniel Hwang
> MetadataTableUtil.getTabletEntries creates ColumnFQ twice unnecessarily
> ---
>
> Key: ACCUMULO-3283
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3283
> Project: Accumulo
> Issue Type: Improvement
> Components: master
>Reporter: Josh Elser
>Assignee: Daniel Hwang
>Priority: Trivial
> Labels: newbie
> Fix For: 1.7.4, 1.8.2, 2.0.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> A new ColumnFQ is created twice using the same value of {{entry.getKey()}}.
> The first value could be retained and used later in the method to avoid the
> extra object creation to be thrown away.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (ACCUMULO-4692) CompactionDriver leaves abandoned metadata scans
Adam Fuchs created ACCUMULO-4692: Summary: CompactionDriver leaves abandoned metadata scans Key: ACCUMULO-4692 URL: https://issues.apache.org/jira/browse/ACCUMULO-4692 Project: Accumulo Issue Type: Bug Components: fate Reporter: Adam Fuchs We wrote a tool to kick off tablet compactions in the background while minimizing compaction load per-server. The tool uses range compaction on one tablet per call. We're seeing a high number of scans on the metadata table (~7,000 on a ~100 node cluster). The metadata query in the isReady() method of CompactionDriver that is used to see if the compaction has completed uses a range that goes to the end of the metadata entries for the given table, but it stops consuming the results of the scanner at the end of the compaction range. isReady gets called in a pretty tight loop, especially with hundreds of compactions running concurrently. Seems like we should limit the scan to the metadata range associated with the compaction so that the scan can get cleaned up quickly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ACCUMULO-3283) MetadataTableUtil.getTabletEntries creates ColumnFQ twice unnecessarily
[
https://issues.apache.org/jira/browse/ACCUMULO-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Tubbs updated ACCUMULO-3283:
Fix Version/s: 1.8.2
1.7.4
> MetadataTableUtil.getTabletEntries creates ColumnFQ twice unnecessarily
> ---
>
> Key: ACCUMULO-3283
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3283
> Project: Accumulo
> Issue Type: Improvement
> Components: master
>Reporter: Josh Elser
>Priority: Trivial
> Labels: newbie
> Fix For: 1.7.4, 1.8.2, 2.0.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A new ColumnFQ is created twice using the same value of {{entry.getKey()}}.
> The first value could be retained and used later in the method to avoid the
> extra object creation to be thrown away.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4688) Consider adding autocomplete=false to the shell servlet's password input element
[
https://issues.apache.org/jira/browse/ACCUMULO-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109736#comment-16109736
]
Josh Elser commented on ACCUMULO-4688:
--
Thanks for sharing your opinion, Christopher. I don't think you should feel
abrasive as this was essentially asking for opinions.
Mike Walch was the only other person who shared one (he was at least +0 for the
change). I'd put myself at a -0.
bq. (Also commented on the GitHub PR... wasn't sure where best to post my
objection and have it received promptly.)
Both of them result an email so they are just as promptly received as the other!
> Consider adding autocomplete=false to the shell servlet's password input
> element
>
>
> Key: ACCUMULO-4688
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4688
> Project: Accumulo
> Issue Type: Improvement
> Components: monitor
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: 1.7.4, 1.8.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Had a report from a user which identified an 'issue" in the ShellServlet
> around the password input element.
> There is an attribute {{autocomplete}} which can be set to false on the
> {{input}} element that will instruct browsers to not try to save the password
> in some store. In theory, this marginally improves security as the password
> would not be stored on the local machine in (potentially) some way that could
> be accessed by an adversary.
> I'm on the fence about the value of making this change (if the browser
> doesn't do this automatically, users would probably do this on their own in a
> way that is *less* secure than how the browser could). Thoughts from everyone
> else?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4688) Consider adding autocomplete=false to the shell servlet's password input element
[
https://issues.apache.org/jira/browse/ACCUMULO-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109718#comment-16109718
]
Christopher Tubbs commented on ACCUMULO-4688:
-
I strongly disagree with this change. I think the premise is flawed. Modern
browsers have secure storage for saved passwords. Having autocomplete enabled,
improves security because it allows longer, more complex, less-memorable
passwords, through the use of a password manager (either the browser's built-in
one, or a third-party one).
In addition, this servlet has been removed in master (2.0.0), so this would
only negatively inconvenience users of 1.7/1.8 upon upgrading to a patch. It
would be unexpected to upgrade, and lose features (security, convenience, etc.).
Sorry if I seem to come off a bit abrasive here, but I feel pretty strongly in
general about websites trying to make security decisions based on restricting
client-side browser features, when I think it's better to let the user decide.
We should secure the server side, and empower users to make their own decisions
in the convenience-vs-security arena for the client side. That's what I think,
anyway.
(Also commented on the GitHub PR... wasn't sure where best to post my objection
and have it received promptly.)
> Consider adding autocomplete=false to the shell servlet's password input
> element
>
>
> Key: ACCUMULO-4688
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4688
> Project: Accumulo
> Issue Type: Improvement
> Components: monitor
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: 1.7.4, 1.8.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Had a report from a user which identified an 'issue" in the ShellServlet
> around the password input element.
> There is an attribute {{autocomplete}} which can be set to false on the
> {{input}} element that will instruct browsers to not try to save the password
> in some store. In theory, this marginally improves security as the password
> would not be stored on the local machine in (potentially) some way that could
> be accessed by an adversary.
> I'm on the fence about the value of making this change (if the browser
> doesn't do this automatically, users would probably do this on their own in a
> way that is *less* secure than how the browser could). Thoughts from everyone
> else?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (ACCUMULO-4680) Replace Namespaces static Strings with actual values from Namespace
[ https://issues.apache.org/jira/browse/ACCUMULO-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4680. -- Resolution: Fixed > Replace Namespaces static Strings with actual values from Namespace > --- > > Key: ACCUMULO-4680 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4680 > Project: Accumulo > Issue Type: Improvement >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Minor > Fix For: 2.0.0 > > > With the extensive work done for ACCUMULO-3238, the static Strings in > Namespaces were replaced with ID objects to minimize changes. These static > Strings can now be dropped and replaced with the new values in Namespace. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4690) Observable configurations
[ https://issues.apache.org/jira/browse/ACCUMULO-4690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109040#comment-16109040 ] Josh Elser commented on ACCUMULO-4690: -- bq. It would be nice if we create an observable mechanism for those changes as well. +1 > Observable configurations > - > > Key: ACCUMULO-4690 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4690 > Project: Accumulo > Issue Type: Improvement > Components: core >Affects Versions: 2.0.0 >Reporter: Ivan Bella >Priority: Minor > > Currently only the table and namespace configurations are observable > (implement ObservableConfiguration). In order to appropriately deal with > system/site configuration changes one needs to use a Timer that periodically > checks the configuration (see TabletServerResourceManager for example). It > would be nice if we create an observable mechanism for those changes as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ACCUMULO-4691) HostRegexBalancer not reacting to configuration changes
Ivan Bella created ACCUMULO-4691: Summary: HostRegexBalancer not reacting to configuration changes Key: ACCUMULO-4691 URL: https://issues.apache.org/jira/browse/ACCUMULO-4691 Project: Accumulo Issue Type: Improvement Affects Versions: 1.8.1 Reporter: Ivan Bella Assignee: Ivan Bella Fix For: 1.8.2, 2.0.0 The HostRegexTableBalancer does not react to changes in the system properties. It listens to the TableConfiguration for changes, but no the base accumulo properties. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ACCUMULO-4690) Observable configurations
Ivan Bella created ACCUMULO-4690: Summary: Observable configurations Key: ACCUMULO-4690 URL: https://issues.apache.org/jira/browse/ACCUMULO-4690 Project: Accumulo Issue Type: Improvement Components: core Affects Versions: 2.0.0 Reporter: Ivan Bella Priority: Minor Currently only the table and namespace configurations are observable (implement ObservableConfiguration). In order to appropriately deal with system/site configuration changes one needs to use a Timer that periodically checks the configuration (see TabletServerResourceManager for example). It would be nice if we create an observable mechanism for those changes as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
