No Project Types visible after installing ArcGIS Pro SDK thru Extensions and Updates

After following the process outlined here (https://github.com/Esri/arcgis-pro-sdk/wiki/ProGuide-Installation-and-Upgrade#install-from-within-visual-studio), I don't see a project type available under the ArcGIS Pro Add-Ins templates. I tried changing the .NET Framework selections and that didn't seem to make any difference.
I am using VS Professional 2015

You need to select a 'required' .Net Framework.  I think it has to be at least 4.6.1, you can see it in the requirements section of our documentation.

Thanks for the tip. Once i selected ".NET Framework 4.6.1", i see the expected project types. Thank you.
I reviewed the Git Hub document at https://github.com/Esri/arcgis-pro-sdk/wiki/ProGuide-Installation-and-Upgrade#install-from-within-visual-studio, and i did not find any reference to requirements around the .NET framework (perhaps i missed it?).  The doc's screenshots show that '.NET Framework' has been selected and not a specific version. Perhaps you guys could add info about the .NET requirement to the document?

It's specific under requirements in a lot a places, however, GitHub's markdown is currently not working as before to a lot of our GitHub links are not working.  Here are the requirements off our landing page (scroll down to supported platforms):
http://pro.arcgis.com/en/pro-app/get-started/arcgis-pro-system-requirements.htm


[FLINK-21673] Add extension points to snapshot reading/wr…

What is the purpose of the change
Trivial refactorings to allow customization
of readers and writers of heap state snapshots.
Verifying this change
This change is a trivial rework without any test coverage.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? no

Build failure unrelated (FLINK-20420), private branch build succeeded.

Thanks for the review @Myasuka. Build failure is unrelated (FLINK-21879), merging.


add OAuth integration so we can do authentication with KeyCloak or the OAuth in OpenShift

This one should be all set with hawtio-oauth


E7.1 devops requirements

Output is in a form they can consume; also address system specific questions apart from log output
to be discussed:

statsd scribe

other ideas:

forward to https://prometheus.io
time-series db (http://opentsdb.net/index.html)

If direct prometheus integration is an option, the ideal for devops would be have an optional prometheus exporter running via cardano (normal http protocol) that could be scraped directly via prometheus. This would bypass the need to write statsd metrics, run a bridge service that receives statsd metrics and then share those metrics via HTTP. If this isn't possible, statsd would be best as that's the integration we already have working with prometheus on the old cardano-sl code base.

A library that might be useful: https://github.com/fimad/prometheus-haskell

1.) EKG -> Prometheus
via https://github.com/fimad/prometheus-haskell
2.) katip -> systemd -> Graylog
katip scribe to journald: https://github.com/haskell-service/katip-libsystemd-journal, from there Graylog can fetch the logs


XmlNode.OuterXml

I am trying to get the outer xml of a node, current it looks like you only have InnerText. is this something that could be added?
EDIT:
An example would be
<Messages>
    <Message Id="1">
        <Name>Foo</Name>
    </Message>
    <Message Id="2">
        <Name>Foo</Name>
    </Message>
</Messages>

And the result of outerxml selecting the first message in Messages.Children should be:
<Message Id="1">
    <Name>Foo</Name>
</Message>

I will add XmlNode.AsRawString(). Is this the function you are looking for?
public struct XmlNode
{
    public RawString AsRawString();
}

<Messages>
    <Message Id="1">
        <Name>Foo</Name>
    </Message>
    <Message Id="2">
        <Name>Foo</Name>
    </Message>
</Messages>

using XmlObject xml = XmlParser.Parse(XmlString);
XmlNode node = xml.FindChild("Message");     // <Message Id="1">

RawString nodeString = node.AsRawString();
/*
nodeString is

"<Message Id="1">
        <Name>Foo</Name>
    </Message>"

*/

Excellent! Yes, it does. But you might be able to tell me if what I'm after is not actually what I want:
I receive a submission document that contains multiple messages. When processing we split the messages up and then use the submission document as a wrapper around each message.
<Submission>
    ...
    <Messages>
       <Message>...</Message>
       <Message>...</Message>
       <Message>...</Message>
    </Messages>
</Submission>

This then becomes (for each message):
<Submission>
    ...
    <Messages>
       <Message>...</Message>
    </Messages>
</Submission>

I have moved feom XmlDocument to XDocument which has nearly halved the speed, but hasn't done much for the allocations.
I am worried though that in doing this with my aforementioned api request with your library is going to significantly increase string allocations instead when building the new documents 🤔

OK, I understand what you want to do.
My new method works without new allocation. It is a slice of the xml.
U8XmlParser is just a parser, which provides the function for reading. All data U8XmlParser provides are readonly.
So you have to use other libraries to create or write a new xml.
So, whether the memory allocation will increase or not depends on the library that creates the xml.
A new version will be released in a few days. Please give it a try. Thank you.


PoC gdbstub for debugging guest programs

A basic gdbstub that allows for debugging VM guest programs.
Example:
First, run the program with GDB on selected port:
let elf = include_bytes!("path to program elf");
let stdin = AthenaStdin::new();
let client = ExecutionClient::new();
client.execute_with_gdb(ELF, stdin.clone(), None, None, None, 9001);

It will spin up GDB server listening on port 9001 and halt the guest program before executing the first instruction. Note that the Rust VM host program is running, not stopped on any breakpoint etc.
Connect with gdb or IDE debugger:
GDB:
> gdb
(gdb) file <path to elf with built with symbols>
(gdb) target remote localhost:9001
(gdb) debug normally

Vscode:
Edit launch.json configuration and add:
{
    "type": "gdb",
    "request": "attach",
    "name": "Attach to guest program",
    "executable": "<path to elf>",
    "target": ":9001",
    "remote": true,
    "cwd": "${workspaceRoot}",
    "valuesFormatting": "parseText",
    "stopAtConnect": true
},

and start debugging with it.

Worth taking a look at this: https://github.com/risc0/risc0/issues/129

I tried adding the recommended configuration to launch.json in vscode but I get a bunch of errors, any idea why?

Found it, it requires this extension: https://marketplace.visualstudio.com/items?itemName=webfreak.debug

A few other notes on getting this to work:

by default athena builds programs without debug info. You need to manually compile the program in question with a command like this:

> RUSTUP_TOOLCHAIN=athena cargo build --target riscv32em-athena-zkvm-elf

and use the path to this binary in the launch.json config.

the default Linux gdb doesn't support the riscv architecture. You need gdb from something like https://github.com/riscv-collab/riscv-gnu-toolchain and then you need to set gdbpath in launch.json as well.
gdb gets a bit confused about where it is, but if you set a breakpoint in the main code and run "c" (continue) it seems to work. Note that the "Step over", "Step into" etc. commands don't seem to work correctly; you need to use breakpoints.

I tried adding the recommended configuration to launch.json in vscode but I get a bunch of errors, any idea why?

You are probably missing GDB debugging extension in VSCode. Try this one: Native Debug

Curious why this is a draft, should we aim to merge this? It's clearly useful. IMHO the only thing missing here is documentation.

Curious why this is a draft, should we aim to merge this? It's clearly useful. IMHO the only thing missing here is documentation.

Yeah, documentation is missing but also because it's very basic support and not everything works perfectly. There are some issues with presenting local variables (I'm not sure if this is issue with the integration or vscode though - e.g. gdb itself prints variables nicely from when asked to with p <variable name>). I'm curious, what problems with stepping did you have?
Also, it would be great to have an option to build guest programs with debug profile (currently release is hardcoded).

by default athena builds programs without debug info. You need to manually compile the program in question with a command like this:

RUSTUP_TOOLCHAIN=athena cargo build --target riscv32em-athena-zkvm-elf

Debug info can be easily turned on with placing this in the Cargo.toml:
[profile.release]
debug=true

I'm curious, what problems with stepping did you have?

It didn't work at all. Every time I tried to step over, in, or out, it was the same as "continue."


[DRAFT] [ENG-5049] Update links to license help guide

Ticket: ENG-5049
Feature flag: n/a

Purpose

Fix broken links to license help guides

Summary of Changes

Update license help guide link on draft registration metadata page
Remove unneeded "License FAQ" link (previous link was broken anyway)
Update "License FAQ" link on collection submission page

Screenshot(s)

On draft registration metadata page

On collection submissions's "Project metadata" panel

Side Effects

QA Notes

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.01%) to 69.029%

Totals

Change from base Build<PHONE_NUMBER>:
-0.01%

Covered Lines:
6076

Relevant Lines:
8550

💛  - Coveralls


fix: tweaking the create service form

Codecov Report

Merging #2140 (b135ef6) into main (7e37570) will not change coverage.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@           Coverage Diff           @@
##             main    #2140   +/-   ##
=======================================
  Coverage   87.07%   87.07%
=======================================
  Files          85       85
  Lines        9312     9312
  Branches      494      494
=======================================
  Hits         8108     8108
  Misses       1204     1204


Subdirectory support

This adds support for creating a Docker image from a subdirectory of a Git repo, rather than just the root.
I wanted to store my Docker image definition and some other configuration in the same repo, without the configuration getting into my image. This seemed like the most straight-forward way to do that.

Thanks for opening this, @dsludwig! Looks good to me. Can you add a test too?

Thanks @yuvipanda, I added a test for this. I couldn't get the pytest capture to pick up the log, but when I run with -s, it does show up.

@dsludwig is there something missing from this PR or can we go ahead and merge it?

@betatim I addressed your comments and resolved the merge conflicts, I think it's ready to go!


x/pkgsite: Please remove github.com/trendmicro/new-release-version/v2

Per #42273 I accidentally created the v2 version of my package.  There is no v2 for github.com/trendmicro/new-release-version.

Done.


[main] Use openshift-knative/hack for net-istio

Context
JIRA: #SRVKS-1058
Changes

Move docker images to the same structure as in Serving
Update release script to no longer check out Dockerfiles to root folder

Tested on https://github.com/openshift/release/pull/39365
/cc @nak3 , @skonto

/lgtm


Remove version: Jackett.Jackett version 0.20.3684

404 - release deleted
Microsoft Reviewers: Open in CodeFlow

URL: https://github.com/Jackett/Jackett/releases/download/v0.20.3684/Jackett.Installer.Windows.exe
Response Error: The remote server returned an error: (404) Not Found.
(Automated message - build 918)


Inconvenience when downloading data/models

Running scripts returns messages as shown below. Now I have to download each file manually.
You may need to change the permission to 'Anyone with the link', or have had many accesses.
You may still be able to access the file from the browser:

	 https://drive.google.com/uc?id=1FHclA4W2ZlaZLdZD06BGkq9Yn5E1f5vH

Access denied with the following error:
Looks like the download did not succeed. If the failure was because the drive download quota exceeded, please wait or install gdrive (https://github.com/prasmussen/gdrive) and run
gdrive download 1FHclA4W2ZlaZLdZD06BGkq9Yn5E1f5vH --path .tmp
mv .tmp/hotpotqa_train_20k.jsonl raw_data/hotpotqa_train_20k.jsonl

Found a trick might save people time: https://medium.com/@acpanjan/download-google-drive-files-using-wget-3c2c025a8b99

Ahh, sorry for the trouble. This used to work when I released the code. I'll try to fix/update it after the ACL deadline this week.

No worries. Thank you for your reply!

Fixed now.


Add Unsupervised ImageFolder

Right now (correct me if i wrong) i can't think of better way of using ImageFolder with unlabeled datasets (e.g. "root/*.png") other than moving directory with samples into another folder and just ignore the fictional labels. So i thought it would be good to have a class that represents such types of datasets.

Indeed you are correct, if you want a dataset of a unlabeled images, you need this crude workaround. But then I think its fair to ask: what would be the use case of such a dataset without labels?

I can see it being used for unsupervised GAN training for image generation, unpaired image-to-image translation with 2 dataloaders representing each class. I personally needed this functionality to test GAN on celeba dataset (i'm just getting started with generative learning).

Yeah, I didn't think of that. Good point!

I recently had a similar problem and solved it with a decorator:
def unsupervise(cls):
    def onlyfirst(__getitem__):
        def __getitem__wrapper(self, idx):
            return __getitem__(self, idx)[0]

        return __getitem__wrapper

    cls.__getitem__ = onlyfirst(cls.__getitem__)

    def __init__wrapper(*args, **kwargs):
        return cls(*args, **kwargs)

    return __init__wrapper

You can use it like this:
from torchvision.datasets import CelebA

@unsupervise
class UnsupervisedCelebA(CelebA):
    pass

While this does not help you if you just want all images of a folder, it allows you to unsupervise an arbitrary dataset without introducing new dataset code.

That's a really neat idea, thanks for sharing that :). It is great solution from the user perspective, but wouldn't that make more sense for library to have support at least for this common kind of datasets (moreover it is not even only specific for images)?

Maybe not in the form of introducing 2 whole new classes for it, we could have a keyword in ImageFolder marking which type is your dataset e.g.
def ImageFolder(*args, samples_only=False, **kwargs):
    if samples_only:
        return UnsupervisedDatasetFolder(*args, **kwargs)
    return DatasetFolder(*args, **kwargs)

The problem with this is that some other class could derive from ImageFolder in someone else's code, so if that solution would suffice mby add a future warning not to derive from it, or do some workaround, or something similar to this. I'd like to hear what others think of it.

It's a just bit unclear to me what is exactly wrong with the initial pull? Is it because it wasn't reviewed yet, or maintainers dislike the idea of introducing 2 new classes for it, or they don't think this functionality is necessary?

After my initial skepticism, I now think the idea behind this PR is valid and should be included. But since I have no say in this we have to wait for @fmassa s feedback if we want this and if yes how we want it.

Hi,
This has been discussed in the past, see https://github.com/pytorch/vision/issues/660
I think there is a very simple solution to this (as pointed in the issue), and I'm not sure we would want to have a dataset for it.
An argument against the current implementation is that it supposes a flat hierarchy of files -- what if we have nested folders with images inside? Should we handle this case as well?
Adding a flag to ImageFolder to conditionally return labels or not would not be ideal IMO, as I would want to avoid having the return type of the datasets to be dependent on the constructor.
Let me know if you disagree.

Hi, thanks for detailed reply. I guess having to write small loader every time from scratch (or making a link to folder with images) isn't that huge of a problem.
The only argument for this PR i have is that people who isn't aware of this yet would expect pytorch to support flat hierarchy datasets (partly because of ImageFolder's uncertain name), which i think is proven by amount of related issues and questions asked. The reason they can't figure out an issue themselves i think is because they get the following misleading exception:
raise (RuntimeError("Found 0 files in subfolders of: " + self.root + "\n"
                    "Supported extensions are: " + ",".join(extensions)))

Do you think it would be a good idea to add hint to what hierarchy should look like ("root/class/*.ext") to the exception?

I think the message is quite clear. It states that it doesn't found any files in the subfolders which hints at hierarchy. If you have a look at the documentation it clearly states how the images have to be arranged.
Thus, I think your question boils down to "can we expect the user to read the documentation before he starts using it"? IMO, yes we can.

Nevertheless, if you search the exception, you'll find multiple issues, answers to which sometimes get highly rated (like this one https://github.com/pytorch/examples/issues/236), i think it would be nice for raised error to straightforwardly hint to the most common mistake.

Do you think its already straightforward enough?

After thinking a little longer i think i agree with you, the problem is easily searchable anyway. I think i'll close the PR now.

Thanks for the PR and the discussion @theonekeyg !
I think this is indeed a recurrent issue, and many custom solutions are possible. One proposed solution was to have a PandasDataset, or a CSVDataset, which handles an arbitrary number of fields.
Still, those solutions are only partially generic, and given the ease of implementing those, I think it might be better to give an example in how to achieve this, instead of providing a function for it.


Dual Boot Crashes The Deck When I Launch Win11

Whenever I try to launch windows a bunch of blue lines appear, and nothing happens after that.

Is this supposed to be enough information for me to help you trouble shoot with?
With that being said, are you trying to boot from Windows from the internal NVMe, SD card or external drive on USB? Did you successfully install Windows previously?  Did it boot okay before? This is minimal information for me to try to help you.

It’s booting from an internal NVME. Windows runs perfectly with all drivers when I use boot manager. It never worked for me I just tried it today

Can you provide a screenshot of what you are talking about, both your rEFInd boot screen and the blue lines screen? Did you have any issues completing the installation? Did you perform the create config and install config steps from the GUI?

Sure I’ll provide both of when I get home. Also can a modded rufus iso be the problem (Removed Windows 11 Requirements)

A modded Rufus iso shouldn't be a problem, I would think (firmware TPM is supported by Steam Deck though by the way). The way my config for the bootloader functions is by pointing to the Windows EFI file to launch. If that EFI file is not there on the /esp partition for some reason, that could be a problem (but solvable with some Windows command prompt commands). Are you able to boot from the Windows EFI file (Vol Up and Power, bottom left option)?
Are you perhaps using BitLocker on the Windows partition? Some other user claimed pointing to the EFI file does not work in that case. I haven't had a chance to double check and test that though.

I’ll just try again and if the issue persists I’ll send the pictures.

Sorry that was an accident

it still doesn’t work and BitLocker is disabled

It’s in the esp partition and boots normally when I hold vol+

Ok. Boot into Windows and make sure that the APU driver is installed and  up to date.
Refer to this portion of the README. Run that command from either command prompt or Powershell, and then try again.

OMG thank you so much. The issue is fixed. Really appreciate it brother.


refactor: move function selector methods out of ABIParser struct

These methods will ultimately be used inside the Sway repository, and
they didn't use the ABIParser fields.

LGTM!


First 3.0.0 release date?

Any news when the first version of 3.0.0 will be released?
Thank you.

:+1:

Nothing specific is planned at this time. No volunteers. :(

Kevin, maybe I'm missing the point but... ok no volunteers but does the
project has a roadmap? does the project has a todo file? a github issue
list?
I think we should start working on this and then look for the volunteers.
Make sense?
paolo
On 14 March 2016 at 18:29, Kevin W. Wall<EMAIL_ADDRESS>wrote:

Nothing specific is planned at this time. No volunteers. :(
—
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-196423883.

--
$ cd /pub
$ more beer
I pirati della sicurezza applicativa: https://codiceinsicuro.it

Most of my energy is spent on ESAPI legacy, which
has quite a few remaining issues and keeps me busy.
(Plus I am also working on the crypto chapter to
the OWASP DevGuide.)
If someone wants to jump in and fork the project,
flesh out the remaining interfaces, that would
help us get started. From there, they can submit
a pull request. Between ESAPI 2.x and OWASP DevGuide,
I don't personally have time to lead ESAPI 3.0 too
unless I get some help--especially if the ZAP Google
Summer of Code that I volunteered for gets selected.
So, please, pitch in. Propose a road map. Propose interfaces!
Help in whatever manner you think you can!
Thanks,
-kevin
On Mon, Mar 14, 2016 at 6:36 PM, Paolo Perego<EMAIL_ADDRESS>wrote:

Kevin, maybe I'm missing the point but... ok no volunteers but does the
project has a roadmap? does the project has a todo file? a github issue
list?
I think we should start working on this and then look for the volunteers.
Make sense?
paolo
On 14 March 2016 at 18:29, Kevin W. Wall<EMAIL_ADDRESS>wrote:

Nothing specific is planned at this time. No volunteers. :(
—
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-196423883.

--
$ cd /pub
$ more beer
I pirati della sicurezza applicativa: https://codiceinsicuro.it
—
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-196550295.

--
Blog: http://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.

Kevin,
Thanks for providing that insight.  I'm onboard to support as time permits, but my time is limited.  Who are the folks with permission to accept merge requests?  If I "at" @ESAPI , will my message land in your inbox?
Thanks,
b-long

Hey Guys,
I can help as well.
Thanks,
Ramzi
2016-03-14 19:00 GMT-04:00 Brian Long<EMAIL_ADDRESS>
Kevin,
Thanks for providing that insight. I'm onboard to support as time permits,
but my time is limited. Who are the folks with permission to accept merge
requests? If I "at" @ESAPI https://github.com/ESAPI , will my message
land in your inbox?
Thanks,
b-long
—
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-196556702.

--
Cheers,
Ramzi

No. My @owasp.org address doesn't seem to be working.
It doesn't bounce (or at least it didn't the last
time I tried it), but simply disappeared into oblivion
rather than showing up at my email address. If you want
to contact me directly, send it to me<EMAIL_ADDRESS>(Yes; that might get me a bit of additional spam too, but
anyone who thinks that spammers haven't figured out
how to parse pseudo-email addresses written like
"kevin DOT w DOT wall AT gmail DOT com" seriously must
be smokin' something.)
On Mon, Mar 14, 2016 at 7:00 PM, Brian Long<EMAIL_ADDRESS>wrote:

Kevin,
Thanks for providing that insight. I'm onboard to support as time permits,
but my time is limited. Who are the folks with permission to accept merge
requests? If I "at" @ESAPI https://github.com/ESAPI , will my message
land in your inbox?
Thanks,
b-long
—
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-196556702.

--
Blog: http://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.

Thanks @ramzimaalej and @kwwall .  I've opened #4 and submitted a pull request to address it.  We'll need someone who is a part of the ESAPI organization to enable Travis.  It's pretty simple if you'd like, I can support that effort.

If you're looking for volunteers, I'm happy to help!  Are you accepting new folks in the ESAPI organization?

All - I've been out of town (and out of touch) for the last weeks - give me
a little time to catch up on this (and a few others) threads over the
weekend and let's come up with a plan of attack early next week. Sound good?
On Tuesday, March 15, 2016, Brian Long<EMAIL_ADDRESS>wrote:

If you're looking for volunteers, I'm happy to help! Are you accepting new
folks in the ESAPI organization?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-196803439

--
~C

On Thu, Mar 17, 2016 at 1:48 PM, Chris Schmidt<EMAIL_ADDRESS>wrote:

All - I've been out of town (and out of touch) for the last weeks - give
me
a little time to catch up on this (and a few others) threads over the
weekend and let's come up with a plan of attack early next week. Sound
good?

@chrisisbeef - works for me. And also throw in your $.02
regarding the Jenkins vs. Travis CI discussion on a
different GitHub issue #1 as well.
Let's just not wait too long because Google Summer of Code
is spinning up again and very soon I'll be knee deep in
a ton of student proposals to review.
-kevin

All -

WRT Roadmap - I checked in /ESAPI-3.0.0-ROADMAP.md highlighting both potential GSoC tasks as well as identifying the high level goals leading to an ESAPI 3.0.0 release.

WRT Travis v. Jenkins - I am partial to Jenkins, however no one presently owns our Jenkins instance (it just kind of chugs along) - if someone is willing to take ownership of either Jenkins or Travis I am impartial to what actually performs the builds. The key to me is that we have a continuous build, a nightly build artifact pushed to Maven Central, and trackable testing. The ability to automate the release process through CI/CD would also be ideal.

One last thing - I will be switching this project to Gitflow (introducing a devel branch and locking master) today. Please fork from devel for any work you would like to do specifically in this project and I will (for now) take the lead on reviewing PR's to devel from your fork.

I've volunteered for esapi-java-legacy, I can volunteer here as well.  I
can handle the CI pieces.  I've never used Travis, but I have used Jenkins
extensively.
On Fri, Mar 25, 2016 at 9:43 AM Chris Schmidt<EMAIL_ADDRESS>wrote:

All -

WRT Roadmap - I checked in /ESAPI-3.0.0-ROADMAP.md highlighting both
potential GSoC tasks as well as identifying the high level goals leading to
an ESAPI 3.0.0 release.

WRT Travis v. Jenkins - I am partial to Jenkins, however no one
presently owns our Jenkins instance (it just kind of chugs along) - if
someone is willing to take ownership of either Jenkins or Travis I am
impartial to what actually performs the builds. The key to me is that we
have a continuous build, a nightly build artifact pushed to Maven Central,
and trackable testing. The ability to automate the release process through
CI/CD would also be ideal.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-201318408

Nobody owning Jenkins is a recipe for #fail.  If we don't have that managed
and patched, any builds off of that are going to be suspect and ripe
targets for bad actors.  There have been 4 RCE vulns in it lately.  I see
it is updated to the patched version at least so that's a good sign.
Jason
On Fri, Mar 25, 2016, 7:45 AM Matt Seil<EMAIL_ADDRESS>wrote:

I've volunteered for esapi-java-legacy, I can volunteer here as well. I
can handle the CI pieces. I've never used Travis, but I have used Jenkins
extensively.
On Fri, Mar 25, 2016 at 9:43 AM Chris Schmidt<EMAIL_ADDRESS>wrote:

All -

WRT Roadmap - I checked in /ESAPI-3.0.0-ROADMAP.md highlighting both
potential GSoC tasks as well as identifying the high level goals leading
to
an ESAPI 3.0.0 release.

WRT Travis v. Jenkins - I am partial to Jenkins, however no one
presently owns our Jenkins instance (it just kind of chugs along) - if
someone is willing to take ownership of either Jenkins or Travis I am
impartial to what actually performs the builds. The key to me is that we
have a continuous build, a nightly build artifact pushed to Maven
Central,
and trackable testing. The ability to automate the release process
through
CI/CD would also be ideal.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-201318408

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-201319361

I can help on configuring Jenkins. Are we going to have a JIRA or we will
stick to github for release management ?
2016-03-25 10:45 GMT-04:00 Matt Seil<EMAIL_ADDRESS>
I've volunteered for esapi-java-legacy, I can volunteer here as well. I
can handle the CI pieces. I've never used Travis, but I have used Jenkins
extensively.
On Fri, Mar 25, 2016 at 9:43 AM Chris Schmidt<EMAIL_ADDRESS>wrote:

All -

WRT Roadmap - I checked in /ESAPI-3.0.0-ROADMAP.md highlighting both
potential GSoC tasks as well as identifying the high level goals leading
to
an ESAPI 3.0.0 release.

WRT Travis v. Jenkins - I am partial to Jenkins, however no one
presently owns our Jenkins instance (it just kind of chugs along) - if
someone is willing to take ownership of either Jenkins or Travis I am
impartial to what actually performs the builds. The key to me is that we
have a continuous build, a nightly build artifact pushed to Maven
Central,
and trackable testing. The ability to automate the release process
through
CI/CD would also be ideal.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-201318408

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-201319361

--
Cheers,
Ramzi

PLEASE... move ESAPI 3.x wherever you want, but LEAVE esapi-java-legacy on
GitHub where it is!!!
-kevin
Sent from my Droid; please excuse typos.
On Mar 25, 2016 10:44 AM, "Chris Schmidt"<EMAIL_ADDRESS>wrote:

One last thing - I will be switching this project to Gitflow (introducing
a devel branch and locking master) today. Please fork from devel for any
work you would like to do specifically in this project and I will (for now)
take the lead on reviewing PR's to devel from your fork.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-201319111

@chrisisbeef Disregard my previous comment. Initially, I thought you were talking about some new Git repository names something like gitflow.org or gitflow.com, but I realize now that you were talking about https://github.com/nvie/gitflow, so go for it!

I'll volunteer, but only if we're going with something more modern than
Jenkins.  It's a huge attack target, and honestly I don't think Jenkins
core is very concerned with feature development and bug fixes. They're
bogged down by exploits.
AppVeyor and Travis are all more robust and free when working in open
source.
On Mar 25, 2016 4:46 PM, "Kevin W. Wall"<EMAIL_ADDRESS>wrote:

@chrisisbeef https://github.com/chrisisbeef Disregard my previous
comment. Initially, I thought you were talking about some new Git
repository names something like gitflow.org or gitflow.com, but I realize
now that you were talking about https://github.com/nvie/gitflow, so go
for it!
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-201492061

I've read the roadmap for GSoC, but it doesn't really give me a clear picture where this is going long term. You plan to wrap the "best available security libs out there" for each purpose behind common interfaces, right? This would make ESAPI something like a "Maven-plug-and-play-security-lib-collection" - is that the idea behind it?
Other than that, where is the unique benefit that ESAPI brings developers instead of just plugging libraries from here-and-there together themselves?
If I'm buying the reason why ESAPI 3.0 is going to be the best thing out there to me, I'm totally willing to help with some implementation, test automation and code analysis stuff...
...so, where's the sales pitch? :moneybag:

@bkimminich - The mission of ESAPI hasn't changed. The execution however is what is changing. ESAPI provides a central repository for security controls that developers can use. More importantly, it provides enterprise organizations with the ability to set a security policy and make security decisions that can be distributed across the entirety of the application portfolio.

As I understand the goal is to have a standardized security API so that
backend implementations can be swapped out.  Other security providers would
have to conform to the OWASP interface, so it would be more or less an open
standard... the sales pitch would be similar to using slf4j instead of
concrete loggers, IMHO.
On Tue, Mar 29, 2016 at 6:50 AM Björn Kimminich<EMAIL_ADDRESS>wrote:

I've read the roadmap for GSoC, but it doesn't really give me a clear
picture where this is going long term. You plan to wrap the "best available
security libs out there" for each purpose behind common interfaces, right?
This would make ESAPI something like a
"Maven-plug-and-play-security-lib-collection" - is that the idea behind it?
Other than that, where is the unique benefit that ESAPI brings developers
instead of just plugging libraries from here-and-there together themselves?
If I'm buying the reason why ESAPI 3.0 is going to be the best thing out
there to me, I'm totally willing to help with some implementation, test
automation and code analysis stuff...
...so, where's the sales pitch? [image: :moneybag:]
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-202847437

Yep. I think that's at least the theory.  The reality is that 99% either
use the ESAPI reference implementation or they don't use that feature at
all. In fact the only exception that I've seen to that is other OWASP
projects making drop in replacements (e.g., AppSensor, Java HTML Sanitizer,
etc.).
The major downside to that IMO is that we have a lot of good security
interfaces in ESAPI that are never used because all we have for the
reference implementation are "toy" PoC implementations (e.g., authN &
authZ). And if someone is building out implementations for them, they
certainly are not being shared.
-kevin
Sent from my Droid; please excuse typos.
On Apr 1, 2016 10:39 AM, "Matt Seil"<EMAIL_ADDRESS>wrote:

As I understand the goal is to have a standardized security API so that
backend implementations can be swapped out. Other security providers would
have to conform to the OWASP interface, so it would be more or less an open
standard... the sales pitch would be similar to using slf4j instead of
concrete loggers, IMHO.
On Tue, Mar 29, 2016 at 6:50 AM Björn Kimminich<EMAIL_ADDRESS>wrote:

I've read the roadmap for GSoC, but it doesn't really give me a clear
picture where this is going long term. You plan to wrap the "best
available
security libs out there" for each purpose behind common interfaces,
right?
This would make ESAPI something like a
"Maven-plug-and-play-security-lib-collection" - is that the idea behind
it?
Other than that, where is the unique benefit that ESAPI brings developers
instead of just plugging libraries from here-and-there together
themselves?
If I'm buying the reason why ESAPI 3.0 is going to be the best thing out
there to me, I'm totally willing to help with some implementation, test
automation and code analysis stuff...
...so, where's the sales pitch? [image: :moneybag:]
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-202847437

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-204420907

I believe that the first milestone should focus on a small set of
interfaces (The most used ones) and provide a RI. We can then extend it
later to add new features. I used OWASP when I was working for an insurance
company. We mostly used the encoder to sanitize log entries and encode
data. IMO, I think we should start off concrete use cases to better
brainstorm the interfaces we need.
2016-04-01 11:19 GMT-04:00 Kevin W. Wall<EMAIL_ADDRESS>
Yep. I think that's at least the theory. The reality is that 99% either
use the ESAPI reference implementation or they don't use that feature at
all. In fact the only exception that I've seen to that is other OWASP
projects making drop in replacements (e.g., AppSensor, Java HTML Sanitizer,
etc.).
The major downside to that IMO is that we have a lot of good security
interfaces in ESAPI that are never used because all we have for the
reference implementation are "toy" PoC implementations (e.g., authN &
authZ). And if someone is building out implementations for them, they
certainly are not being shared.
-kevin
Sent from my Droid; please excuse typos.
On Apr 1, 2016 10:39 AM, "Matt Seil"<EMAIL_ADDRESS>wrote:

As I understand the goal is to have a standardized security API so that
backend implementations can be swapped out. Other security providers
would
have to conform to the OWASP interface, so it would be more or less an
open
standard... the sales pitch would be similar to using slf4j instead of
concrete loggers, IMHO.
On Tue, Mar 29, 2016 at 6:50 AM Björn Kimminich <
<EMAIL_ADDRESS>wrote:

I've read the roadmap for GSoC, but it doesn't really give me a clear
picture where this is going long term. You plan to wrap the "best
available
security libs out there" for each purpose behind common interfaces,
right?
This would make ESAPI something like a
"Maven-plug-and-play-security-lib-collection" - is that the idea behind
it?
Other than that, where is the unique benefit that ESAPI brings
developers
instead of just plugging libraries from here-and-there together
themselves?
If I'm buying the reason why ESAPI 3.0 is going to be the best thing
out
there to me, I'm totally willing to help with some implementation, test
automation and code analysis stuff...
...so, where's the sales pitch? [image: :moneybag:]
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-202847437

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-204420907

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-204435811

--
Cheers,
Ramzi

I would be very interested to know if anyone IS building out authentication
implementations... in my experience, (all with big companies) they use
something like Oracle OAM/OID tied into LDAP, so there's little drive for
an auth implementation.
On Fri, Apr 1, 2016 at 10:19 AM Kevin W. Wall<EMAIL_ADDRESS>wrote:

Yep. I think that's at least the theory. The reality is that 99% either
use the ESAPI reference implementation or they don't use that feature at
all. In fact the only exception that I've seen to that is other OWASP
projects making drop in replacements (e.g., AppSensor, Java HTML Sanitizer,
etc.).
The major downside to that IMO is that we have a lot of good security
interfaces in ESAPI that are never used because all we have for the
reference implementation are "toy" PoC implementations (e.g., authN &
authZ). And if someone is building out implementations for them, they
certainly are not being shared.
-kevin
Sent from my Droid; please excuse typos.
On Apr 1, 2016 10:39 AM, "Matt Seil"<EMAIL_ADDRESS>wrote:

As I understand the goal is to have a standardized security API so that
backend implementations can be swapped out. Other security providers
would
have to conform to the OWASP interface, so it would be more or less an
open
standard... the sales pitch would be similar to using slf4j instead of
concrete loggers, IMHO.
On Tue, Mar 29, 2016 at 6:50 AM Björn Kimminich <
<EMAIL_ADDRESS>wrote:

I've read the roadmap for GSoC, but it doesn't really give me a clear
picture where this is going long term. You plan to wrap the "best
available
security libs out there" for each purpose behind common interfaces,
right?
This would make ESAPI something like a
"Maven-plug-and-play-security-lib-collection" - is that the idea behind
it?
Other than that, where is the unique benefit that ESAPI brings
developers
instead of just plugging libraries from here-and-there together
themselves?
If I'm buying the reason why ESAPI 3.0 is going to be the best thing
out
there to me, I'm totally willing to help with some implementation, test
automation and code analysis stuff...
...so, where's the sales pitch? [image: :moneybag:]
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-202847437

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-204420907

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-204435811

Here's the problem guys - everyone's needs are completely different, and more often than not, even when people need the same controls, they need those controls implemented in different ways with different rules or leveraging different platforms. The aim of ESAPI 3.x was to allow people to truly use ESAPI as an API, there should be no focus on a RI because that's how ESAPI ended up the bloated massive framework that it has become. The focus of 3.x is to provide the interfaces and an extensible and pluggable framework wherein controls can be plugged in. This will allow enterprises and small development shops alike to use ESAPI without having a bunch of (as Kevin likes to call it) toy code and bloat that they will never use while providing all the benefits of a centrally managed repository of security controls that developers can use.
Does that clarify?

On Sun, Apr 3, 2016 at 11:54 PM, Matt Seil<EMAIL_ADDRESS>wrote:

I would be very interested to know if anyone IS building out authentication
implementations... in my experience, (all with big companies) they use
something like Oracle OAM/OID tied into LDAP, so there's little drive for
an auth implementation.
On Fri, Apr 1, 2016 at 10:19 AM Kevin W. Wall<EMAIL_ADDRESS>wrote:

Yep. I think that's at least the theory. The reality is that 99% either
use the ESAPI reference implementation or they don't use that feature at
all. In fact the only exception that I've seen to that is other OWASP
projects making drop in replacements (e.g., AppSensor, Java HTML
Sanitizer,
etc.).
The major downside to that IMO is that we have a lot of good security
interfaces in ESAPI that are never used because all we have for the
reference implementation are "toy" PoC implementations (e.g., authN &
authZ). And if someone is building out implementations for them, they
certainly are not being shared.

I've spent the past 5 years in two primary capacities working for 2
different F200 companies--one in the telecom sector and one in the
financial sector--doing secure architect / design reviews and secure code
reviews respectively. During those 5 years, I have the perspective of being
involved with close 200+ different (total) applications from 2 different
companies. I did not keep exact figures, but if I had to hazard a guess
based on my recollection (which shouldn't probably be trusted as I usually
can't even remember what I ate for supper 2 days ago :), I would say that
25-35% of those applications built their own custom authentication system
(90% of which used some sort of custom DB schema), around 30-40% used some
sort of corporate directory solution (e.g., Active Directory, Integrated
Windows Authentication, or corporate LDAP), and the remaining 25-45% used
some sort of COTS web access management solution such as RSA Access
Manager, CA SiteMinder, or Oracle OAM/OID. In my security architect
reviewer role, I tried to steer people towards the WAM solution or at least
towards something like IWA/AD/LDAP and away from a custom solution. But
there is a lot more legacy software out there then one might realize. The
strong "selling" point of WAM solutions is that they offer cheap yet
simplistic (non-federated) SSO out-of-the-box. I think situation is much
different in green field applications where they likely would chose a COTS
security appliance if there is enterprise support for one and if their
isn't they might choose something like some OAuth2 implementation or
something supported out of the box by Spring Security, etc.
As an aside, I always felt that we blew it in not at least providing a
simple LDAP reference implementation based on JNDI for ESAPI 2.x. That is
very simple to implement and at least realistically useful (assuming one as
a corporate LDAP infrastructure, which you do if you have Windows AD). The
downside is that it would make testing it using JUnit a minor PITA since
most ESAPI developers do not run there own LDAP servers on the dev boxes.
Today, that probably isn't a major obstacle as one could set that up and
deploy using some lightweight container management tool such as Docker,
Vagrant, Puppet, Chef, etc. Sure, the container management would be an
additional test-time dependency, but it would n ot be a run-time
dependency. But back in the day when ESAPI 2.0 was first being rolled out
all we had were more heavyweight VMs and many of us did not have the needed
CPU or memory to get decent performance from those. Had we provided a
reference implementation for authN, then some of the ESAPI Java servlet
filters would also have been useful and I think we would have seen those
have become heavily used ESAPI components, not quite as frequently used as
ESAPI encoders and validators, but definitely more than an occasional blip
on the radar.
But hindsight is 20/20. I think our biggest mistake by far was trying to
build a monolithic system--one security library to serve them all.
Anyhow, I've already rambled on long enough for this to be another TL;DR
post.

kevin
--
Blog: http://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.

On Mon, Apr 4, 2016 at 10:05 AM, Chris Schmidt<EMAIL_ADDRESS>wrote:

Here's the problem guys - everyone's needs are completely different, and
more often than not, even when people need the same controls, they need
those controls implemented in different ways with different rules or
leveraging different platforms. The aim of ESAPI 3.x was to allow people to
truly use ESAPI as an API, there should be no focus on a RI because
that's how ESAPI ended up the bloated massive framework that it has
become. The focus of 3.x is to provide the interfaces and an extensible and
pluggable framework wherein controls can be plugged in. This will allow
enterprises and small development shops alike to use ESAPI without having a
bunch of (as Kevin likes to call it) toy code and bloat that they will
never use while providing all the benefits of a centrally managed
repository of security controls that developers can use.
Does that clarify?

Well, it makes sense to me, and I buy into the general sentiment at least.
There is no doubt that ESAPI 2.x and earlier was designed as a bunch of
monolithic components. (But even if we had zero RI for ESAPI, I still think
that the 2.x and earlier interfaces were a little too co-mingled for my
taste. Indeed if that were not the case, why not just keep all the
interfaces as-is for ESAPI 3.0 and simply ditch the reference
implementation?)
However, I also want to say on thing here...except for very rare occasions
where you are working either with either recognized standards bodies (like
IETF, W3C, ISO, NIST, etc.) or a large industry-backed consortium, having a
minimally useful working
model (which is at least one step up from a "toy" implementation IMO) is
essential, to getting developers to adopt your interfaces / API. In part,
it goes back to that "the proof is in the pudding" mentality, but more-so,
we hackers have to have something to get our hands on and be able to take
apart and see how it works and put it back together (albeit possibly
differently). A RI is important in being able to "play" with the API to see
what it can do, to see how it can be extended. That is not to say that we
need to write out own RI; we can get a lot of mileage by just taking
someone else's Encoder (say) and packing them up by wrapping them behind
some glue to our new interfaces.  But we MUST NOT 1) deploy the RI as
though it were part of the interfaces, and 2) deploy all the RI as one
large monolithic RI jar.
I have always felt that the UNIX philosophy minimalist, modular software
was the right approach. Each module doing one thing well, but having the
ability to "hook into" other modules somehow. I am somewhat cautiously
optimistic about the whole micro-services movement (versus the more
monolithic SOA components that the past 10 years have tended toward). If we
don't make the same security mistakes all over again (which, is the main
reason for my caution), we could actually come out ahead. People are
finally starting to realize the downside of software bloatware in terms of
its added complexity, performance impact, etc. If you aren't interested in
using it, then you shouldn't be forced to carry it around as part of your
application.
Now, having said that, I think that we have a difficult task ahead of us.
The expectations of developers who have used ESAPI are hire so 3.0 has to
be way better than 2.x for them to let the latter go. (And while we could
kill off 2.x officially now, I personally think that completely sends the
wrong message. If we do that, I think dev teams considering adopting 3.0
will look and say "they dropped 2.x just like that and didn't support those
users so what assurance do I have that they will support 3.0?) So that's
one thing. The other is that this time around, I think it's going to be
much more difficult getting a core group of volunteers on a long term basis
to see this through. Chris and I are willing to help but we cannot carry
the entire load ourselves.

kevin
--
Blog: http://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.

I agree empirically with nearly everything @kwwall says here - the need to modernize and componentize ESAPI in a meaningful way that aligns with the way software is both written (framework-centric development) and deployed (micro-services) in modern applications is important, as is the ability to continue to support enterprise and legacy applications. The ability for an enterprise security team to distribute a central policy that is enforced in their entire application suite is as important as it is for the developer implementing a set of micro services for their mobile app to be able to quickly re-use policy and controls that they have used in the past, and the ability swap components in and out of the api on an as-needed basis (or consequently implement multiple controls to solve the same set of problems based on the constraints at runtime. Additionally the need for things to just happen is becoming more and more important - as a developer I should never have to explicitly verify a user is authenticated or output is escaped in the correct context, because we have proven time and again that when left to their own devices the vast majority of developers will do it wrong - not because they are incapable, but because they don't understand the intricacies (nor should they have to) of contextual property aware escaping or exactly how to ensure the validity of an OAuth token. These concerns all matter and should be reflected in the design of the API.

Count me in as a willing contributor. I've worked on the Legacy ESAPI a few years back, ~2009 (I think).

At one point I contributed a JNDI LDAP implementation to OWASP AppSensor,
although I don't know if they are still using it. Still, the implementation
is easy enough and on the plus side, doesn't require any additional
dependencies. IF we are going to provide a reference implementation, to
me, that seems the better way to go than using a DB as almost everyone can
either stand up an OpenLDAP instance or point it an AD LDAP interface. Of
course, IMHO, the reason that it probably has not been done is because it
makes the JUnit tests for authentication way more complicated because all
of a sudden you have a dependency of a DB or LDAP instance that you have to
preload with some data. I suppose we could figure all of that out using
some sort of container like Docker, Vagrant, etc, or extensive scripting
but it's difficult to make portable and back in 2009, I don't think light
weight containers were probably viable options.
-kevin
Blog: http://off-the-wall-security.blogspot.com/  |  Twitter:  @KevinWWall
NSA: All your crypto bit are belong to us.
On Apr 3, 2016 23:54, "Matt Seil"<EMAIL_ADDRESS>wrote:

I would be very interested to know if anyone IS building out authentication
implementations... in my experience, (all with big companies) they use
something like Oracle OAM/OID tied into LDAP, so there's little drive for
an auth implementation.
On Fri, Apr 1, 2016 at 10:19 AM Kevin W. Wall<EMAIL_ADDRESS>wrote:

Yep. I think that's at least the theory. The reality is that 99% either
use the ESAPI reference implementation or they don't use that feature at
all. In fact the only exception that I've seen to that is other OWASP
projects making drop in replacements (e.g., AppSensor, Java HTML
Sanitizer,
etc.).
The major downside to that IMO is that we have a lot of good security
interfaces in ESAPI that are never used because all we have for the
reference implementation are "toy" PoC implementations (e.g., authN &
authZ). And if someone is building out implementations for them, they
certainly are not being shared.
-kevin
Sent from my Droid; please excuse typos.
On Apr 1, 2016 10:39 AM, "Matt Seil"<EMAIL_ADDRESS>wrote:

As I understand the goal is to have a standardized security API so that
backend implementations can be swapped out. Other security providers
would
have to conform to the OWASP interface, so it would be more or less an
open
standard... the sales pitch would be similar to using slf4j instead of
concrete loggers, IMHO.
On Tue, Mar 29, 2016 at 6:50 AM Björn Kimminich <
<EMAIL_ADDRESS>wrote:

I've read the roadmap for GSoC, but it doesn't really give me a clear
picture where this is going long term. You plan to wrap the "best
available
security libs out there" for each purpose behind common interfaces,
right?
This would make ESAPI something like a
"Maven-plug-and-play-security-lib-collection" - is that the idea
behind
it?
Other than that, where is the unique benefit that ESAPI brings
developers
instead of just plugging libraries from here-and-there together
themselves?
If I'm buying the reason why ESAPI 3.0 is going to be the best thing
out
there to me, I'm totally willing to help with some implementation,
test
automation and code analysis stuff...
...so, where's the sales pitch? [image: :moneybag:]
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
<https://github.com/ESAPI/esapi-java/issues/3#issuecomment-202847437

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-204420907

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-204435811

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/ESAPI/esapi-java/issues/3#issuecomment-205123441

@kwwall I am very interested to help as I am maintaining the ESAPI for my enterprise. There are a few fixes and enhancements on ESAPI <IP_ADDRESS> readily for contribution.

@jackycct I am glad to hear that and we are eager to receive your contributions. However ESAPI 2.x is being maintained and developed under https://github.com/ESAPI/esapi-java-legacy, not here. This was intended to be for ESAPI 3.0, or ESAPI "next generation" if you will. Unfortunately, it never gained much traction and it's pretty much that all Matt (@xeno6696) and I can try to fix bugs in the ESAPI 2.x release and periodically put out a new release of that.
For starters, check out the README.md file in ESAPI 2.x, especially the section "Contributing to ESAPI legacy". If you need more information, the best way to contact the ESAPI developers is through the ESAPI-Developers mailing list mentioned at the end of the README file.

Thanks @kwwall for your prompt reply.
I plan to contribute some dependencies upgrade to resolve opensource vulnerabilities as a start. Does it make sense to contribute to 2.x or 3.x?

@jackycct Starting with ESAPI 2.x definitely makes more sense at this point. However, if you look at the latest pom.xml in the 'develop' branch as well as the PR for issue #419 for ESAPI 2.x that I pushed but is not yet merged, I think that covers all the vulnerable dependencies recognized by OWASP Dependency Check. Although feel free to double-check.
As far as the next ESAPI 2.x release, we've run into a bit of a hiccup in regards to some tests that have started failing that are pointing to deeper issues. @xeno6696 and @jeremiahjstacey  are working that issue, but I feel its important enough to address before we push out a release.
In regards to ESAPI 3.x, I think there's a lot to debate there. One one hand, I'm not comfortable with all the current ESAPI 2.x interfaces (especially some of the crypto ones, which is where I've been focused), so I think it's fair game to propose alternatives for 3.x (if / when we ever get to that). But OTOH, I've seen first hand the disaster that resulted from (in part at least) from the lack of an adequate migration plan from Struts 1.x to Struts 2.x. Even to this day, I still encounter Struts 1.x applications. I don't want that to happen with ESAPI so we have to address such issues up front.
Anyway, for anyone wanting to continue the discussion of this, please sign up and more the discussion to the ESAPI-Developers mailing list. At this point, I'm closing this issue with an official "I don't know when the first ESAPI 3.0 release will be. It is still very much TBD."


Add BR/EDR Scanning Capability to the Bumble

Currently the Bumble controller does not support Bluetooth "classic" (BR/EDR) scanning. It only has BLE scanning support.
This issue is to request that Bumble be updated to support Bluetooth classic scanning.
I'm still investigating the full impact of this, but at a minimum it will require adding the BR/EDR scanning HCI commands to the controller.

Note: I'm working on these updates myself. But, I wanted to put this ticket in to share what I'm doing and get feedback from the community (if any).

Well this turned into a huge effort..... Current status: functionally tested, but working on cleaning up unit tests before I do a PR.


[Menu] “.inverted.secondary.pointing.menu” shouldn’t have a border all around its container; only at the bottom

Hello!
I came across an issue with the border on the secondary pointing menu element. An example will say more than thousand words:
...
%div.ui.container
    %div.ui.secondary.pointing.inverted.menu
      %a.item.active Foo
      %a.item Bar

What we see, is this kinda strange border:

After some time digging in the source, I found out that there are two classes named  .ui.secondary.inverted.pointing.menu, as one of them is probably invalid: https://github.com/Semantic-Org/Semantic-UI/blob/master/src/definitions/collections/menu.less#L980-L987

@TomiCode what’s weird about it? It looks intended considering that @secondaryPointingInvertedBorderColor that’s being overriden is rgba(255, 255, 255, 0.1)—the border is subtle, but it’s still visible. In any case, do you need help overriding the default rule?
Also, in the future, please fork this JSFiddle to demonstrate bugs as per the contributing guidelines.

Ups.. Sorry I missed that, with the jsfiddle..: http://jsfiddle.net/efp8z6Ln/454/
What's weird about it?
I don't think that the inverted secondary pointing menu should define a border all around the container itself. There should be only a bottom line for this menu element.

Updated the Fiddle to use SSL links -- I couldn't see it otherwise:
https://jsfiddle.net/efp8z6Ln/455/
Agree with the OP, having a border only for inverted colors is inconsistent.

I am still experiencing this issue. Here is what I got installed:
$ yarn list | grep semantic
├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>│  ├─<EMAIL_ADDRESS>Please advise, thanks!


Memory Issue In Buffers

Hello,
I have a large array that needs to be sent over a socket connection from a server (Node Js) to a Client (Holo Js / Hololens) every second or so. Sending it as a normal array is kind of slow so i resorted to converting the list to a buffer.
var buffer = new Float64Array(list).buffer
var data = {
	buffer : buffer
}
client.emit('sendData', data);

However, I realized that the app would crash and start throwing an out of memory exception after a while. After looking into it more i realized that the memory displayed on the diagnostic tools view in visual studio keeps increasing every time a new buffer is being received. This does not happen when receiving a normal array.
I attached a sample node js server
NodeJs - Socket Server.zip
And here is a small script to run on HoloJs to replicate the problem.
var url = "http://{ip}:{port}/";
var socket = io(url, { transports: ['websocket'] });

socket.on('connect', function () {
    console.log('connected');
    socket.emit('requestData');
});

socket.on('sendData', function (data) {
    socket.emit('requestData');
});

Another thing i tried that caused the same behavior is this:

setInterval(function () {
    var test = [];
    for (var i = 0; i < 100000; i++) {
        test.push(i);
    }
    var data = {
        test: test
    };
   // console.log(data);
}, 100);

When i comment out the console.log no issues happen but adding it would cause the memory to keep increasing until eventually the app crashes due to an out of memory exception.
Regards,
Omar.

Thank you Cristi, its working great now and memory is stable. Please note that i get this error sometimes:
Exception thrown at 0x77442552 in ThreeJSApp-Vs2017.exe: Microsoft C++ exception: Js::RejitException at memory location 0x087FF117.
but it seems that it doesn't affect anything and the script just keeps running normally.


HDFS-17390. [FGL] FSDirectory supports this fine-grained locking

FSDirectory should holds read or write lock of FSLock, since it just involves directory tree-related operations.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 35s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+0 :ok:
xmllint
0m  1s

xmllint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 3 new or modified test files.

_ HDFS-17384 Compile Tests _

+1 :green_heart:
mvninstall
44m 57s

HDFS-17384 passed

+1 :green_heart:
compile
1m 22s

HDFS-17384 passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
1m 17s

HDFS-17384 passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
checkstyle
1m 22s

HDFS-17384 passed

+1 :green_heart:
mvnsite
1m 28s

HDFS-17384 passed

+1 :green_heart:
javadoc
1m 10s

HDFS-17384 passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 44s

HDFS-17384 passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
3m 26s

HDFS-17384 passed

+1 :green_heart:
shadedclient
38m 45s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

-1 :x:
mvninstall
0m 24s
/patch-mvninstall-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
compile
0m 24s
/patch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javac
0m 24s
/patch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
compile
0m 24s
/patch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
javac
0m 24s
/patch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
1m  4s
/results-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs-project/hadoop-hdfs: The patch generated 49 new + 353 unchanged - 8 fixed = 402 total (was 361)

-1 :x:
mvnsite
0m 25s
/patch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
javadoc
0m 23s
/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javadoc
0m 24s
/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
spotbugs
0m 25s
/patch-spotbugs-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
shadedclient
12m  8s

patch has errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
0m 25s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

+1 :green_heart:
asflicense
0m 34s

The patch does not generate ASF License warnings.

111m 59s

Subsystem
Report/Notes

Docker
ClientAPI=1.44 ServerAPI=1.44 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6573/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6573

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets xmllint

uname
Linux 8507150ee60e 5.15.0-94-generic #104-Ubuntu SMP Tue Jan 9 15:25:40 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
HDFS-17384 / a9ecac4bfc5d2e305307e18e12940a89780d4018

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6573/1/testReport/

Max. process+thread count
653 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6573/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 21s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
xmllint
0m  0s

xmllint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 3 new or modified test files.

_ HDFS-17384 Compile Tests _

-1 :x:
mvninstall
0m 22s
/branch-mvninstall-root.txt
root in HDFS-17384 failed.

-1 :x:
compile
0m 23s
/branch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in HDFS-17384 failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
compile
0m 22s
/branch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs in HDFS-17384 failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-0 :warning:
checkstyle
0m 20s
/buildtool-branch-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt
The patch fails to run checkstyle in hadoop-hdfs

-1 :x:
mvnsite
0m 22s
/branch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in HDFS-17384 failed.

-1 :x:
javadoc
0m 23s
/branch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in HDFS-17384 failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javadoc
0m 22s
/branch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs in HDFS-17384 failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
spotbugs
0m 22s
/branch-spotbugs-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in HDFS-17384 failed.

+1 :green_heart:
shadedclient
2m 33s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

-1 :x:
mvninstall
0m 21s
/patch-mvninstall-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
compile
0m 22s
/patch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javac
0m 22s
/patch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
compile
0m 22s
/patch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
javac
0m 22s
/patch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 20s
/buildtool-patch-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt
The patch fails to run checkstyle in hadoop-hdfs

-1 :x:
mvnsite
0m 22s
/patch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
javadoc
0m 22s
/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javadoc
0m 22s
/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
spotbugs
0m 22s
/patch-spotbugs-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

+1 :green_heart:
shadedclient
4m 13s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
0m 22s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

+0 :ok:
asflicense
0m 22s

ASF License check generated no output?

13m  8s

Subsystem
Report/Notes

Docker
ClientAPI=1.44 ServerAPI=1.44 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6573/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6573

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets xmllint

uname
Linux 03f05e2a5ebe 5.15.0-94-generic #104-Ubuntu SMP Tue Jan 9 15:25:40 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
HDFS-17384 / 3fb07a08ef56b02bf731c69f12239c9f23f77bf1

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6573/2/testReport/

Max. process+thread count
33 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6573/2/console

versions
git=2.25.1 maven=3.6.3

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 23s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
xmllint
0m  0s

xmllint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 3 new or modified test files.

_ HDFS-17384 Compile Tests _

-1 :x:
mvninstall
0m 21s
/branch-mvninstall-root.txt
root in HDFS-17384 failed.

-1 :x:
compile
0m 22s
/branch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in HDFS-17384 failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
compile
0m 22s
/branch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs in HDFS-17384 failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-0 :warning:
checkstyle
0m 20s
/buildtool-branch-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt
The patch fails to run checkstyle in hadoop-hdfs

-1 :x:
mvnsite
0m 22s
/branch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in HDFS-17384 failed.

-1 :x:
javadoc
0m 22s
/branch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in HDFS-17384 failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javadoc
0m 22s
/branch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs in HDFS-17384 failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
spotbugs
0m 22s
/branch-spotbugs-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in HDFS-17384 failed.

+1 :green_heart:
shadedclient
2m 33s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

-1 :x:
mvninstall
0m 22s
/patch-mvninstall-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
compile
0m 22s
/patch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javac
0m 22s
/patch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
compile
0m 22s
/patch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
javac
0m 22s
/patch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 20s
/buildtool-patch-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt
The patch fails to run checkstyle in hadoop-hdfs

-1 :x:
mvnsite
0m 22s
/patch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
javadoc
0m 22s
/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javadoc
0m 22s
/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
spotbugs
0m 22s
/patch-spotbugs-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

+1 :green_heart:
shadedclient
4m 13s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
0m 23s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

+0 :ok:
asflicense
0m 22s

ASF License check generated no output?

13m  9s

Subsystem
Report/Notes

Docker
ClientAPI=1.44 ServerAPI=1.44 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6573/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6573

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets xmllint

uname
Linux ca223795a0b9 5.15.0-94-generic #104-Ubuntu SMP Tue Jan 9 15:25:40 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
HDFS-17384 / df5db0761acaeda11cc6882d407a005b0e6e7831

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6573/3/testReport/

Max. process+thread count
22 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6573/3/console

versions
git=2.25.1 maven=3.6.3

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
7m 38s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ HDFS-17384 Compile Tests _

+1 :green_heart:
mvninstall
32m 27s

HDFS-17384 passed

+1 :green_heart:
compile
0m 43s

HDFS-17384 passed with JDK Ubuntu-11.0.22+7-post-Ubuntu-0ubuntu220.04.1

+1 :green_heart:
compile
0m 40s

HDFS-17384 passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
checkstyle
0m 36s

HDFS-17384 passed

+1 :green_heart:
mvnsite
0m 43s

HDFS-17384 passed

+1 :green_heart:
javadoc
0m 39s

HDFS-17384 passed with JDK Ubuntu-11.0.22+7-post-Ubuntu-0ubuntu220.04.1

+1 :green_heart:
javadoc
1m  2s

HDFS-17384 passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
1m 40s

HDFS-17384 passed

+1 :green_heart:
shadedclient
20m 19s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 35s

the patch passed

+1 :green_heart:
compile
0m 37s

the patch passed with JDK Ubuntu-11.0.22+7-post-Ubuntu-0ubuntu220.04.1

+1 :green_heart:
javac
0m 37s

the patch passed

+1 :green_heart:
compile
0m 34s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
javac
0m 34s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 31s

the patch passed

+1 :green_heart:
mvnsite
0m 34s

the patch passed

+1 :green_heart:
javadoc
0m 29s

the patch passed with JDK Ubuntu-11.0.22+7-post-Ubuntu-0ubuntu220.04.1

+1 :green_heart:
javadoc
1m  1s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
1m 39s

the patch passed

+1 :green_heart:
shadedclient
20m 12s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
199m 58s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 27s

The patch does not generate ASF License warnings.

294m 24s

Reason
Tests

Failed junit tests
hadoop.hdfs.tools.TestDFSAdmin

hadoop.hdfs.server.datanode.TestLargeBlockReport

hadoop.hdfs.server.namenode.TestNamenodeRetryCache

hadoop.hdfs.server.namenode.fgl.TestFineGrainedFSNamesystemLock

hadoop.hdfs.protocol.TestBlockListAsLongs

Subsystem
Report/Notes

Docker
ClientAPI=1.44 ServerAPI=1.44 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6573/5/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6573

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 6a01c2d19c1c 5.15.0-94-generic #104-Ubuntu SMP Tue Jan 9 15:25:40 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
HDFS-17384 / 2662542a85540840dc2d47939413056ccbdfe728

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.22+7-post-Ubuntu-0ubuntu220.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6573/5/testReport/

Max. process+thread count
4887 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6573/5/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

Failed cases are unrelated.

Thanks for the patch. Merged.


Typescript 2.4

@isiahmeadows, @andraaspar  I've added the branch ts2.4 to experiment with solutions. Running npm i will install TS2.4.
I've added @andraaspar's most recent updates currently in PR at DT. (Failing tests commented out because I haven't setup DT's linting system for this repo.)
This branch also contains default generic parameters that I'd like to submit in a followup PR. (See here for example.)
Currently the Lifecycle type has an additional member to get around the new "weak types" checking feature in TS2.4. This leaves us with slightly weaker component types. Using a numeric key improves the situation but it's not quite perfect. (You could write component[0].)
There is also this outstanding problem with ClassComponent: https://github.com/spacejack/mithril.d.ts/issues/21

@spacejack Would it be better if we just unified component instances like below and then just inlined Lifecycle's members into the component and attrs types? It'd also fix #21 by side effect.

Object components: interface Component<Attrs, State extends Component<Attrs, State>> { ... }
Class components: new <S extends Component<Attrs, S>>(vnode: Vnode<Attrs, S>) => S
Closure components: <S extends Component<Attrs, S>>(vnode: Vnode<Attrs, never>) => S

(Note that I preserve the State extends Component invariant for objects, even though core doesn't require it.)

@isiahmeadows I'm a bit stumped on this one, it seems to lead down a rabbit-hole of inlining (there are also Vnode types to consider.)
I looked at moving view into Lifecycle, but then State doesn't satisfy the constraints.

What other nodes implicitly implement Lifecycle?


filesystems: Add autoResize assertion

Motivation for this change
Assert that autoResize is only used when fsType is explicitly set to a
supported filesystem: if it's set to "auto", the default, the required
resizing tools won't be copied into the initrd even if the actual
filesystem is supported.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

I don't know why you are handling fs2fs as well since it seems to me resizing tools are only imported for ext* FS: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/stage-1.nix#L131

Confusingly enough, it is, but not in stage-1.nix: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/filesystems/f2fs.nix

@talyz ok, thanks!
BTW, would be nice to centralize this...


[WIP] Build with alpine instead of ubuntu

Reduces image size from ~280 MB to ~99MB

@MariusBierlein pleaaase don't merge it yet, apparently is not working as expected...


Click-axis-to-reset-brush does not work with multi brush?

The multi brush feature works nicely, but in that mode it seems we can no longer click on the axis to clear the brushes.
In single-brush mode, it click-to-reset still works fine.
This can be seen in the included demo for multi-brushes.

@ManiacalAce Thank you for your understanding.
In fact I've worked on this for two nights in the last week, but didn't solve this.
I want to fix this bug in the coming week.

@ManiacalAce Done.
v2.0.6 has been released with the bug-fix.

Nice!
Has this been published to npm? I still get 2.0.5 as latest from npm install.

Are you using the brush.html for testing?

@ManiacalAce I haven't got your idea yet.
When chart is loaded without any brush action, let's call this the initial state.

In 1D-axes mode:  add a brush, click axis to reset brush of the axis, chart is restored to the initial state.
In 1D-axes-multi mode, add two brushes on one axis, click axis to reset brushes of the axis, chart is restored to the initial state, too.

Behaviors of click-to-reset feature are consistent in both 1D-axes mode and 1D-axes-multi mode.
From your description, I guess we may have different observations. Which demo page did you use?

@BigFatDog Sorry for the delay. I'll get back to you with a concrete example in 5-6 hours. I wasn't using the included examples - I was basing it off of observations in my product where we use this lib.
The gist of it is that it seems like in multi mode, clicking to reset seems to select everything on the chart.
Let me re-verify and get back to you by evening.

@BigFatDog Seems like my issue stems from something else related to colors.
I was trying to have one color for regular, untouched stuff, and a different color for brushed items - which i could swear was possible in the original fork of this lib.
For example, If I have this (with color and brushedColor)
    var pc = ParCoords({nullValueSeparator: "bottom"})("#example")
        .data([
            [0,-0,0,0,0,1],
            [1,-1,1,2,1,1],
            [2,,4,4,0.5,1],
            [3,,9,6,,],
            [4,-4,16,8,0.25,1]
        ])
        .color('#0000ff')
        .render()
        .shadows()
        .createAxes()
        .reorderable()
        .brushMode("1D-axes-multi")
        .brushedColor('#ff0000')

Initially, the lines are blue, as expected. Then when I brush some items, they become red. Then, when I click to reset, everything is red (when I expect it to be blue).


add support for yescrypt

Dear Nikki VonHollen,
how do you think about adding yescrypt support as the default encryption method?
Kind regards
Harald Jenny

Nikki isn't working on this anymore, TTBOMK.
Given that it is the default in Debian is yescrypt now (apart from some other players, we would certainly accept a pull request to do that change. We aren't likely to do the change ourselves though (at least not yet), since we are not using it internally in policycache.

Hi Sven Mueller,
first thanks for your reply and I'm sorry that Nikky isn't working on this anymore. I'm thinking of doing the necessary changes but IMHO this would likely be more invasive as I would switch from libscrypt to libxcrypt. May I ask what hashing algorithm you use internally because I think of dropping both crypt and SHA256 as they are considered insecure.
Kind regards
Harald Jenny

Can you point to where in the code you'd like to change?
I am not a cryptographer, but aren't yescrypt and scrypt are key derivation functions? If we were going to change to something, wouldn't something like bcrypt be better?
Why is SHA256 insecure? google.com uses a HTTPS certificate with a SHA256 signature, for example.

Hi Eric,
first thanks for your reply - the change in the code would affect the codebase in src/entry.h and src/entry.c where the whole crypto coding is done, I guess I will first do a POC with recoding the current algorithms for xcrypt usage.
You're right considering the KDF functionality as according to https://www.openwall.com/yescrypt/: yescrypt is a password-based key derivation function (KDF) and password hashing scheme. It builds upon Colin Percival's scrypt.
and https://en.wikipedia.org/wiki/Scrypt: In cryptography, scrypt (pronounced "ess crypt"[1]) is a password-based key derivation function created by Colin Percival, originally for the Tarsnap online backup service.
while https://en.wikipedia.org/wiki/Bcrypt: bcrypt is a password-hashing function designed by Niels Provos and David Mazières, based on the Blowfish cipher and presented at USENIX in 1999.
On the other hand xscypt as used by most distributions declares in https://manpages.debian.org/unstable/libcrypt-dev/crypt.5.en.html: yescrypt is a scalable passphrase hashing scheme designed by Solar Designer, which is based on Colin Percival's scrypt. Recommended for new hashes.
So I guess staying with yescrypt as the default password hashing scheme would stay in line with current recommendations, also when considering the limitations of bcrypt described on this page.
Considering the problem with SHA256: While the normal signature is still considered secure (although I personally prefer SHA512 or SHA3-512) the following line in https://manpages.debian.org/unstable/libcrypt-dev/crypt.5.en.html make me a little bit worried: Acceptable for new hashes. The default CPU time cost parameter is 5000, which is too low for modern hardware.
So I guess while using SHA256 in password hashing per default does not pose a security risk the CPU time cost parameter would need to be adapted to provide a better protection against attacks.
So my proposal would be to add yescrypt as default while keeping scrypt and maybe also SHA256 with an increased CPU time cost parameter (not sure how high we should go), removing standard crypt and therefore maybe adding SHA512 (with increased CPU time cost parameter) and brypt as available hashes. While I'm not very eager to add new configuration options I would maybe add a hash and CPU time cost parameter option to the module so users could finetune their defaults.
Hope this answers all your questions Eric if not please come back to me.
Wish you a nice day
Harald

So, I had a brief look at the source and realized that for most parts, this is actually using libcrypt1/xcrypt (via libglib, g_checksum_new, which calls g_checksum_reset here: https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gchecksum.c line 1470ff and 1494ff) - which in turn doesn't support YesCrypt.
libpam_policycache would only use scrypt when scrypt is used for the caching entry (via CacheEntryPasswordSet) - which is the case, unconditionally, with the current code. The code has a TODO to make this algo configurable. (Which was never done unfortunately.)
So to achieve your goal, you might need to patch GNOME GLib before touching libpam-policycache. Or pretty heavily change how libpam-policycache handles these hashes. I'd hate it if we would add special code to directly use xcrypt/YesCrypt if we could possibly get GLib to support it and then leverage that support.

Hi Sven,
sorry to say but that is just one branch of the code which is used for SHA256, the current relevant code with scrypt directly uses the scrypt libscrypt_scrypt function.
The most important codebase for me is the CACHE_ENTRY_ALGORITHM_CRYPT code path which uses crypt_r which is also exported by libxcrypt. Doing some prelimiary coding I was able to make libpam-policycache use CRYPT, SHA256 and SCRYPT from libxcrypt as well as adding YESCRYPT support.
So I guess the better solution would be to port libpam-policycache to use all the algos directly from libxcrypt than adding only YesCrypt support to GNOME GLib.
Above all this would keep libpam-policycache in line with other pam auth modules which also use libxcrypt (like pam_unix and pam_pwdfile). And it would also make it easy to support new password hashing algorithms like for example Argon when they get implemented in libxcrypt.
Bye
Harald


Counter goes back to zero when switching to different page

It's the first time I've tried this. I wish on terminal, there was an instruction  Open http://localhost:1337 in your browser. It just said Server listening on port 1337. I wasn't sure if react-universally runs 2 services(a client and api).
$ cross-env DEPLOYMENT=development babel-node internal/development
==> VENDORDLL -> Generating a new "client" Vendor DLL for boosted development performance.
The Vendor DLL helps to speed up your development workflow by reducing Webpack build times.  It does this by seperating Vendor DLLs from your primary bundles, thereby allowing Webpack to ignore them when having to rebuild your code for changes.  We recommend that you add all your client bundle specific dependencies to the Vendor DLL configuration (within /config).
==> VENDORDLL -> Vendor DLL build complete. The following dependencies have been included:
	-react
	-react-async-component
	-react-dom
	-react-helmet
	-react-router-dom

==> Creating a development bundle configuration for the "client"
webpack building...
==> CLIENT -> Building new bundle...
webpack built 25a494fb3ac95427d774 in 3506ms
==> CLIENT -> Running with latest changes.
==> Creating a development bundle configuration for the "server"
==> SERVER -> Building new bundle...
==> SERVER -> Server running with latest changes.
Server listening on port 1337

Anyways, my real question as about the Counter variable. Every time I switch to different different tabs like Home, About, the counter I incremented doesn't keep the value. It always reset it to zero. Is this a bug or this was intentional? I hope it kept the last value so people won't think there is an issue in the code. I really thought it was a bug.

Yes, for the sake of simplicity we don't ship a system-wide store for keeping state between components. You can see that the initial state is set in the constructor of the counter route.
You will want to use something like mobx or redux to keep the state.

Thank you.


Provide a way to persist folded regions

Purpose would be to restore the editor in the folded state it was.

There is a public property AllCodeFoldingRanges that contains the information. What kind of situation you have?

Had missed it, I was looking under the CodeFolding class