Unable to resolve parameters defined in a WorkflowTemplate

Summary
What happened/what you expected to happen?
A workflow should be able to use a workflow template that contains parameters but it failed to resolve the parameters defined in a WorkflowTemplate.
 We need all of your diagnostics, please make sure you add it all, otherwise we'll go around in circles asking you for it:
What Kubernetes provider are you using?
k3s
What version of Argo Workflows are you running?
3.2.0-rc1
What executor are you running? Docker/K8SAPI/Kubelet/PNS/Emissary
PNS
Did this work in a previous version? I.e. is it a regression?
Haven't checked.
Are you pasting thousands of log lines? That's too much information.
# Either a workflow that reproduces the bug, or paste you whole workflow YAML, including status, something like:
kubectl get wf -o yaml ${workflow}

Name:         hello-world-template-args-not-working-hngpc
Namespace:    argo
Labels:       workflows.argoproj.io/completed=true
              workflows.argoproj.io/phase=Failed
Annotations:  <none>
API Version:  argoproj.io/v1alpha1
Kind:         Workflow
Metadata:
  Creation Timestamp:  2021-09-07T02:31:23Z
  Generate Name:       hello-world-template-args-not-working-
  Generation:          2
  Managed Fields:
    API Version:  argoproj.io/v1alpha1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:generateName:
      f:spec:
        .:
        f:entrypoint:
        f:serviceAccountName:
    Manager:      kubectl-create
    Operation:    Update
    Time:         2021-09-07T02:31:23Z
    API Version:  argoproj.io/v1alpha1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:labels:
          .:
          f:workflows.argoproj.io/completed:
          f:workflows.argoproj.io/phase:
      f:spec:
        f:arguments:
        f:templates:
      f:status:
        .:
        f:conditions:
        f:finishedAt:
        f:message:
        f:phase:
        f:progress:
        f:startedAt:
        f:storedTemplates:
    Manager:         workflow-controller
    Operation:       Update
    Time:            2021-09-07T02:31:23Z
  Resource Version:  27323
  UID:               ede4eb8e-c43e-4571-a74b-c3c827dff82a
Spec:
  Arguments:
  Entrypoint:            whalesay
  Service Account Name:  argo
  Templates:
    Inputs:
    Metadata:
    Name:  whalesay
    Outputs:
    Steps:
      [map[arguments:map[] name:hello-world templateRef:map[name:hello-world-template-args-not-working template:hello-world]]]
Status:
  Conditions:
    Status:     True
    Type:       Completed
  Finished At:  2021-09-07T02:31:23Z
  Message:      invalid spec: templates.whalesay.steps[0].hello-world templates.hello-world: failed to resolve {{workflow.parameters.local-parameter}}
  Phase:        Failed
  Progress:     0/0
  Started At:   2021-09-07T02:31:23Z
  Stored Templates:
    namespaced/hello-world-template-args-not-working/hello-world:
      Container:
        Args:
          {{workflow.parameters.local-parameter}}
        Command:
          cowsay
        Image:  docker/whalesay
        Name:
        Resources:
      Inputs:
      Metadata:
      Name:  hello-world
      Outputs:
Events:
  Type     Reason          Age    From                 Message
  ----     ------          ----   ----                 -------
  Warning  WorkflowFailed  3m19s  workflow-controller  invalid spec: templates.whalesay.steps[0].hello-world templates.hello-world: failed to resolve {{workflow.parameters.local-parameter}}

Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

You can’t refer spec level fields if you are referring ‘ templateRef’. In your scenario, the workflow which referring ‘templateRef’ should have spec level parameter.
Sent from my iPhone

On Sep 6, 2021, at 7:39 PM, Yuan Tang @.***> wrote:

Summary
What happened/what you expected to happen?
A workflow should be able to use a workflow template that contains parameters but it failed to resolve the parameters defined in a WorkflowTemplate.
 We need all of your diagnostics, please make sure you add it all, otherwise we'll go around in circles asking you for it:
What Kubernetes provider are you using?
k3s
What version of Argo Workflows are you running?
3.2.0-rc1
What executor are you running? Docker/K8SAPI/Kubelet/PNS/Emissary
PNS
Did this work in a previous version? I.e. is it a regression?
Haven't checked.
Are you pasting thousands of log lines? That's too much information.
Either a workflow that reproduces the bug, or paste you whole workflow YAML, including status, something like:
kubectl get wf -o yaml ${workflow}
Name:         hello-world-template-args-not-working-hngpc
Namespace:    argo
Labels:       workflows.argoproj.io/completed=true
workflows.argoproj.io/phase=Failed
Annotations:
API Version:  argoproj.io/v1alpha1
Kind:         Workflow
Metadata:
Creation Timestamp:  2021-09-07T02:31:23Z
Generate Name:       hello-world-template-args-not-working-
Generation:          2
Managed Fields:
API Version:  argoproj.io/v1alpha1
Fields Type:  FieldsV1
fieldsV1:
f:metadata:
f:generateName:
f:spec:
.:
f:entrypoint:
f:serviceAccountName:
Manager:      kubectl-create
Operation:    Update
Time:         2021-09-07T02:31:23Z
API Version:  argoproj.io/v1alpha1
Fields Type:  FieldsV1
fieldsV1:
f:metadata:
f:labels:
.:
f:workflows.argoproj.io/completed:
f:workflows.argoproj.io/phase:
f:spec:
f:arguments:
f:templates:
f:status:
.:
f:conditions:
f:finishedAt:
f:message:
f:phase:
f:progress:
f:startedAt:
f:storedTemplates:
Manager:         workflow-controller
Operation:       Update
Time:            2021-09-07T02:31:23Z
Resource Version:  27323
UID:               ede4eb8e-c43e-4571-a74b-c3c827dff82a
Spec:
Arguments:
Entrypoint:            whalesay
Service Account Name:  argo
Templates:
Inputs:
Metadata:
Name:  whalesay
Outputs:
Steps:
[map[arguments:map[] name:hello-world templateRef:map[name:hello-world-template-args-not-working template:hello-world]]]
Status:
Conditions:
Status:     True
Type:       Completed
Finished At:  2021-09-07T02:31:23Z
Message:      invalid spec: templates.whalesay.steps[0].hello-world templates.hello-world: failed to resolve {{workflow.parameters.local-parameter}}
Phase:        Failed
Progress:     0/0
Started At:   2021-09-07T02:31:23Z
Stored Templates:
namespaced/hello-world-template-args-not-working/hello-world:
Container:
Args:
{{workflow.parameters.local-parameter}}
Command:
cowsay
Image:  docker/whalesay
Name:
Resources:
Inputs:
Metadata:
Name:  hello-world
Outputs:
Events:
Type     Reason          Age    From                 Message

Warning  WorkflowFailed  3m19s  workflow-controller  invalid spec: templates.whalesay.steps[0].hello-world templates.hello-world: failed to resolve {{workflow.parameters.local-parameter}}
Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

Thanks. Just tried and both of the following workflows work. Though it looks like local variable values must be supplied at the template definition inside WorkflowTemplate. Is this the normal behavior? If so, I'll add something to the doc that clarifies this.
Global variable
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: hello-world-template-args-not-working-4
spec:
  serviceAccountName: argo
  templates:
    - name: hello-world
      container:
        image: docker/whalesay
        command: [cowsay]
        args: ["{{workflow.parameters.global-parameter}}"]
---
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: hello-world-template-args-not-working-
spec:
  serviceAccountName: argo
  entrypoint: whalesay
  arguments:
    parameters:
      - name: global
        value: hello
  templates:
    - name: whalesay
      steps:
        - - name: hello-world
            templateRef:
              name: hello-world-template-args-not-working-4
              template: hello-world

Local variable (value must be supplied at the template definition inside WorkflowTemplate.
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: hello-world-template-args-not-working-11
spec:
  serviceAccountName: argo
  templates:
    - name: hello-world
      inputs:
        parameters:
          - name: msg
            value: "hi msg"
      container:
        image: docker/whalesay
        command: [cowsay]
        args: ["{{inputs.parameters.msg}}"]
---
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: hello-world-template-args-not-working-
spec:
  serviceAccountName: argo
  entrypoint: whalesay
  templates:
    - name: whalesay
      steps:
        - - name: hello-world
            templateRef:
              name: hello-world-template-args-not-working-11
              template: hello-world

Yes it is expected behavior. You can achieve in both way. You can directly refer global variable or you can pass as local parameter.
I prefer local parameters so, always call will pass it no confusion
Sent from my iPhone

On Sep 6, 2021, at 8:38 PM, Yuan Tang @.***> wrote:

Thanks. Just tried and both of the following workflows work. Though it looks like local variable values must be supplied at the template definition inside WorkflowTemplate. Is this the normal behavior? If so, I'll add something to the doc that clarifies this.
Global variable
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
name: hello-world-template-args-not-working-4
spec:
serviceAccountName: argo
templates:
- name: hello-world
container:
image: docker/whalesay
command: [cowsay]
args: ["{{workflow.parameters.global-parameter}}"]
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: hello-world-template-args-not-working-
spec:
serviceAccountName: argo
entrypoint: whalesay
arguments:
parameters:
- name: global
value: hello
templates:
- name: whalesay
steps:
- - name: hello-world
templateRef:
name: hello-world-template-args-not-working-4
template: hello-world
Local variable (value must be supplied at the template definition inside WorkflowTemplate.
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
name: hello-world-template-args-not-working-11
spec:
serviceAccountName: argo
templates:
- name: hello-world
inputs:
parameters:
- name: msg
value: "hi msg"
container:
image: docker/whalesay
command: [cowsay]
args: ["{{inputs.parameters.msg}}"]
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: hello-world-template-args-not-working-
spec:
serviceAccountName: argo
entrypoint: whalesay
templates:
- name: whalesay
steps:
- - name: hello-world
templateRef:
name: hello-world-template-args-not-working-11
template: hello-world
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.


fix/naming

Codecov Report
Patch coverage: 100.00% and no project coverage change.

Comparison is base (3e7e82b) 100.00% compared to head (14503f6) 100.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff            @@
##            master       #39   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           28        28
  Lines          856       856
  Branches       123       123
=========================================
  Hits           856       856

Impacted Files
Coverage Δ

contracts/libs/data-structures/StringSet.sol
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Refactor Resolver

This will refactor resolver to work with
multiple edge case scenarios
Submitter Checklist

[ ] 📝 Please ensure your commit message is clear and informative. For guidance on crafting effective commit messages, refer to the How to write a git commit message guide. We prefer the commit message to be included in the PR body itself rather than a link to an external website (ie: Jira ticket).

[ ] ♽ Before submitting a PR, run make test lint to avoid unnecessary CI processing. For an even more efficient workflow, consider installing pre-commit and running pre-commit install in the root of this repository.

[ ] ✨ We use linters to maintain clean and consistent code. Please ensure you've run make lint before submitting a PR. Some linters offer a --fix mode, which can be executed with the command make fix-linters (ensure markdownlint and golangci-lint tools are installed first).

[ ] 📖 If you're introducing a user-facing feature or changing existing behavior, please ensure it's properly documented.

[ ] 🧪 While 100% coverage isn't a requirement, we encourage unit tests for any code changes where possible.

[ ] 🎁 If feasible, please check if an end-to-end test can be added. See README for more details.

[ ] 🔎 If there's any flakiness in the CI tests, don't necessarily ignore it. It's better to address the issue before merging, or provide a valid reason to bypass it if fixing isn't possible (e.g., token rate limitations).

/retest

@piyush-garg Thank you for the PR

Can you add e2e to cover the scenario which is described in this https://issues.redhat.com/browse/SRVKP-4018 and https://issues.redhat.com/browse/SRVKP-3517 which gives confidence that PR works in those cases

Will this PR covers this issue https://issues.redhat.com/browse/SRVKP-3973 ?

/test

@piyush-garg
error message
[notice] A new release of pip is available: 23.2.1 -> 24.2
[notice] To update, run: pip install --upgrade pip
3: B6 Body message is missing

/retest

@piyush-garg Thank you for the PR

Can you add e2e to cover the scenario which is described in this https://issues.redhat.com/browse/SRVKP-4018 and https://issues.redhat.com/browse/SRVKP-3517 which gives confidence that PR works in those cases
Will this PR covers this issue https://issues.redhat.com/browse/SRVKP-3973 ?

Added e2e tests for all three

/test

LGTM
tested and reviewed this and this looks good, thanks @piyush-garg


Enable flattr Support for HubPress Bloggers

I've just signed up for a flattr account and was wondering what a great fit it would be to have a way of automatically embedding a flattr button in blog posts or the main Ghost themes.
The way I suspect it could work would be to add a flattr button to Settings => Blog Settings like we have for the Google Analytics ID.

I'm closing this one off, and suggesting that if you want to promote a contribution system for your blogs you may consider using paypal.me as an easy way to allow folks to donate.


Feature: Select Model without using Record-IDs

Is your feature request related to a problem?
Select a Model by using e.g. a Username instead of a Record ID
Describe the solution
i think it would be better to select a model by like using a username from a column instead to use a record id.
Alternative methods
I came to an idea to add something like a .where("key", "value") method to the end of driver.select(...) Example: User user = driver.select("table", User.class).where("key", "value"))
SurrealDB version
1.0.0-beta.9+20230402.5eafebd for windows on x86_64
Contact Details
No response
Is there an existing issue for this?

[x] I have searched the existing issues

Code of Conduct

[x] I agree to follow this project's Code of Conduct

With version 0.2.0, the select method is now declined with several variants, allowing to select a table.
https://surrealdb.github.io/surrealdb.java/javadoc/com/surrealdb/Surreal.html#select(java.lang.Class,java.lang.String)


datatypes: Handle missing optional lists and objects

Fix #489
@victai, could you please check if this PR fixes your issue?

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

:exclamation: No coverage uploaded for pull request base (main@82b4a2e). Click here to learn what that means.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #492   +/-   ##
=======================================
  Coverage        ?   81.18%
=======================================
  Files           ?       45
  Lines           ?     4559
  Branches        ?        0
=======================================
  Hits            ?     3701
  Misses          ?      858
  Partials        ?        0

Flag
Coverage Δ

unittests
81.18% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Yes, it's fixed. Thank you! Closes #489


Eiger: Working INTS and EXTS

Ticket to track progress on a working Eiger simulation with the following features:

INTS mode
EXTS mode
Input trigger signal
Odin compatibility

Network adapters will need changing.

Resolved with #54


chore: Testing chaining of jobs

This PR aims at testing the chaining of jobs. Do not merge this in.

Confirmed, working as expected.

stage job
stage_oss_sonatype job
publish_javadocs11 job

Closing this.


Update drawing.cpp

https://github.com/Itseez/opencv/commit/f2decec3e887dd1539e9613a6eaafe4980e25252
https://github.com/Itseez/opencv/commit/dff7037156779920c3094cad64e828a66b8b9873#commitcomment-13622775
two fixes merged. i think no need to deleted lines.
@berak could you confirm it please.

@sturkmen72, thank you for the patch, but this fix looks dangerous to me, I do not want the mentioned bug with crash to return and it's not immediately obvious to me that the following function logic handle the case of empty strings well


build - set no-sandbox everywhere

The intent is to always have --no-sandbox as argument on Linux to prevent issues such as https://github.com/microsoft/vscode/issues/81056
@joaomoreno @Tyriar please let me know if you can think of yet another place where we need to set this. I feel we have the following entry points:

from the command line ("code"): should be handled via the change in cli.ts
from the window manager: hopefully covered by the changes to the .desktop files
from invoking the executable directly: as far as I can tell we cannot do anything about that usage

NOTE: issue does not appear when running Electron as node!


rRNA Contamination checks?

Hi!
just because it came up recently: One could indeed use RSEQC to check with a given BED file for rRNA contamination / incomplete depletion of rRNA using a BED file of such positions. That could serve as an additional QC / optional step... any thoughts on this?
Would only require adding these BED files for rRNA positions on the respective genomes I guess and using the script provided by RSEQC already...

I think we need to decide which QC software we are going to use first - RseqC or Qualimap or both. You can extract ribosomal intervals from the gtf file using biotype on the fly and then feed that to a downstream QC tool in the required format. I do that with RNASeqC and it works quite well.

That would be super nice! Especially fetching the intervals automatically.. Might need to add support to MultiQC 🙄

If there would be not only an rRNA check but even a rRNA depletion process, maybe by e.g. SortMeRNA against a 16S database such as SILVA than this pipeline might also work for environmental metatranscriptomics.


Some achievements can only be completed by using the QR scanner on the hub

Currently the only way for a user to complete automatic achievements is to use our qr scanner on the hub. The reason behind is that the hub expects to receive a POST request with the information about which achievement the user is trying to complete. I made it expect a POST request so that the user would need to use our custom QR scanner which has additional logic to handle such requests with the hope of making it a little bit harder to cheat.
However, it does not seem to be possible to implement a completely reliable QR scanner on the web which would work on all devices. For this reason we should change the system such that the users would be able to interact with the achievements system through 3rd party QR scanners.
The simplest solution would probably be to remove the requirement of receiving the information through a POST request and changing it with a simple GET request which can be sent by any QR scanner.

When the person clicks on the link to complete the achievement, it will take them to a page (using the GET request). Then if we perform a redirect to the achievement page with a flash message it should be a bit harder for people to cheat since they might not have time to get the link.


Automated cherry pick of #4459: Upgrade Antrea base image to ubuntu:22.04

Cherry pick of #4459 on release-1.7.
#4459: Upgrade Antrea base image to ubuntu:22.04
For details on the cherry pick process, see the cherry pick requests page.

@tnqn @antoninbas  I removed the dpkg -i /tmp/ovs-debs/*.deb in the OVS Ubuntu Dockerfile. Otherwise, it will try to upgrade the OVS packages instead of using our debs.

/test-all

@tnqn @antoninbas I removed the dpkg -i /tmp/ovs-debs/*.deb in the OVS Ubuntu Dockerfile. Otherwise, it will try to upgrade the OVS packages instead of using our debs.

I assume you mean apt-get -f -y --no-install-recommends install would upgrade the OVS packages, then does the issue exist in main branch too?

@tnqn @antoninbas I removed the dpkg -i /tmp/ovs-debs/*.deb in the OVS Ubuntu Dockerfile. Otherwise, it will try to upgrade the OVS packages instead of using our debs.

I assume you mean apt-get -f -y --no-install-recommends install would upgrade the OVS packages, then does the issue exist in main branch too?

During my test if we keep the dpkg -i  step and use apt -f —no-install-recommends install  to fix the dependencies, it will try to upgrade the ovs packages (2.17.0 to 2.17.3)
The following packages will be upgraded:
  openvswitch-common openvswitch-ipsec openvswitch-switch python3-openvswitch

I have tested and did not observe this in main branch. Perhaps it is because that we upgraded OVS to 2.17.3 in main branch as well.

@xliuxu that's fine by me and it makes sense: it's the first time the OVS version that we ship is "older" than the version of OVS provided by the distribution, which explains the automatic upgrade.
However, in my opinion this change should also be included in the main branch.


PHRACK.ORG LINKS

http://www.phrack.org/archives/issues/

                              ==Phrack Inc.==

                Volume 0x0f, Issue 0x45, Phile #0x01 of 0x10

|=-----------------------------------------------------------------------=|
|=-------------------------=[ Introduction ]=----------------------------=|
|=-----------------------------------------------------------------------=|
|=----------------------=[ by the Phrack staff ]=------------------------=|
|=-----------------------=[<EMAIL_ADDRESS>]=--------------------------=|
|=-----------------------------------------------------------------------=|
|=-------------------------=[  May 6, 2016  ]=---------------------------=|
|=-----------------------------------------------------------------------=|

               ... A long time ago in a galaxy far far away ...

                     ______ _                    _
                     | ___ \ |                  | |
                     | |_/ / |__  _ __ __ _  ___| | __
                     |  __/| '_ \| '__/ _` |/ __| |/ /
                     | |   | | | | | | (_| | (__|   <
                     \_|   |_| |_|_|  \__,_|\___|_|\_\

                            _  _    ____  _____
                          _| || |_ / ___||  _  |
                         |_  __  _/ /___ | |_| |
                          _| || |_| ___ \\____ |
                         |_  __  _| \_/ |.___/ /
                           |_||_| \_____/\____/

--[ Introduction

Hello Phrack readers! It has been a long time, hasn't it? Aren't you
relieved that the world didn't end in 2012?! What if the Mayans were right?
What if comets hit Earth? Yes, we were worried too, so we decided to take
some time off and enjoy the last days of this planet. Once enough time had
passed, we were pretty sure our species was not going to disappear. It was
about time we returned to our blinking terminals again and finish what we
started :>

Um... yeah, that's the reason the last Phrack release was back in 2012...
Um... Kind of...

Damn, it took so long that even a Star Wars sequel was shot in the
meantime!

Anywayz, the Phrack Staff is back again, with a slightly different
editorial, bringing you an awesome collection of articles from several
respected hackers and other thinkers. No, we are not going to write a
Prophile on our new team. Yes, there are still people who prefer Phrack
over media whoring. The world is full of surprises. It took quite some
time, but we hope this issue of Phrack will meet your expectations.

One new addition to Phrack is the "Paper Feed" feature. The way it works is
that you submit a paper, we review it and it gets published. No need to
wait a month (or two years ;-) until you see your article in the next
Phrack issue. When the time has come, we'll decide to compile a new issue
from the articles that have been submitted. The usual rules do however
still apply: we are proud of being one of the longest-running magazines and
we're especially proud of presenting quality content to our readers (yes,
that's you). Papers submitted to the paper feed are no exception!

Phrack #69 brings you three new technical articles in addition to paper
feed and the standard Linenoise, Loopback and International Scenes philes.
The Firefox hater code-named argp presents advanced exploitation techniques
and attempts to build abstract primitives for taking advantage of various
memory-related vulnerabilities on your "favorite" multi-heap browser ;>
Huku, some guy who, obviously, visits porn sites a lot, has written an art
of exploitation phile focusing on Adobe Flash Player (hey, this is not
P0 man!). Last but not least, uty presents a VT-x based technique for
installing inline hooks and backdooring a whole system. We have spent much
time debugging this, we hope you *do* like it.

This release also comes with an excellent prophile on Solar Designer, a
person we all respect for his knowledge, attitude and contributions. We
were initially hesitant to contact him (yeah this guy has a damn busy
schedule), but it turned out that Solar was positive about being
prophiled. We believe this prophile will inspire a lot of people in the
scene - it's undoubtedly one of the best prophiles ever published in Phrack
and a great honor for all readers.

Enjoy maafakaz!

--[ Dark thoughts about the future

As we mentioned above, you have probably noticed a big change in the way
Phrack papers are released. We have decided to also have a paper feed mode
in addition to periodic releases, where each submitted work, that meets the
requirements, is released as soon as it has undergone proper reviewing. We
understand that this may not be as cool as releasing an issue at once, but
it was a necessary choice we had to make to avoid having Phrack fade out of
existence. The hope with this, is that now all you crazy world traveling,
conference speaking rockstars may have a medium for releasing a deeper dive
into the technology that you are presenting, and we can publish this at
the exact moment you are on stage. Personally, we would much prefer this
than trying to extract it ourselves from your pretty slide decks.

I guess we are all responsible for this. The community as a whole. The
hackers, the phreakers and all those tech perverts out there who have
stopped supporting Phrack. Trust me you would be disappointed if you had a
look at our inbox... or maybe no one uses ANTISPAM anymore? :>

For all you hackers out there thinking "I don't have a large project
ready for paper generation", consider writing something for Linenoise.
Linenoise submissions take between a few hours and one day. As a community
everyone has some small technique or cool trick that can save other people
time, Linenoise offers an easy place to share these.

In this issue you will find a very interesting article titled "The Fall of
Hacker Groups".  The state of mind of the community seems to be changing
dramatically - what have you done to prevent hacking from practically
disappearing?

Quoting Phrack #63:

    "As long as there are hackers, there will be PHRACK magazine."

Now take some time, read this issue carefully, and notice the "as long as"
part in the previous sentence :>

--[ Table of contents

  0x01  Introduction ........................................ Phrack Staff

  0x02  Phrack Prophile on Solar Designer ................... Phrack Staff

  0x03  Phrack World News ................................... Phrack Staff

  0x04  Linenoise ........................................... various

  0x05  Loopback ............................................ Phrack Staff

  0x06  The Fall of Hacker Groups ........................... strauss

  0x07  Revisiting Mac OS X Kernel Rootkits ................. fG!

  0x08  Adobe Shockwave:
        A case study on memory disclosure ................... Aaron Portnoy

  0x09  Modern Objective-C Exploitation Techniques .......... nemo

  0x0a  Self-patching Microsoft XML with misalignments
        and factorials ...................................... Alisa Esage

  0x0b  Internet Voting: A Requiem for the Dream ............ kerrnel

  0x0c  Attacking Ruby on Rails Applications ................ joernchen

  0x0d  Obituary for an Adobe Flash Player bug .............. huku

  0x0e  OR'LYEH? The Shadow over Firefox .................... argp

  0x0f  How to hide a hook: A hypervisor for rootkits ....... uty & saman

  0x10  International Scenes ................................ various

--[ Greetings & thanks

For this issue we have a long list of people we would like to thank. This
issue wouldn't be complete had it not been for their support.

  * strauss       : Straus.. staruss... strsauss.. whatever man!
  * fG!           : The legendary white hat(ed) hero!
  * Aaron Portnoy : Real name detected!
  * nemo          : That lolcat you see in various memes ;-)
  * Alisa Esage   : Knows how to write exploits and doesn't work for P0
  * kerrnel       : What's with the extra "r"?
  * joernchen     : Ruby two-handed fapper
  * argp          : Hardcore Shakira fan - Favorite song "Heaps don't lie"
  * huku          : Casual youporn uploader
  * sysk          : Proud yolo Phrack supporter
  * uty & saman   : Makefiles suck!
  * solardiz      : Awesomeness prophiled
  * fjserna       : Guest reviewer of, well, you can figure out what
  * anonymous     : You know who you are, thanks for you support!

Last but not least, Phrack Staff is indebted to <redacted> *wink *wink*
for his support all these years. You have our respect for everything you
have offered to this magazine. We are now in different teams, but we will
always be glad to have some beers with you and talk about dirty hacks ;>
See you soon man!

Phrack is back!

--[ Phrack policy

phrack:~# head -77 /usr/include/std-disclaimer.h
/*
 *  All information in Phrack Magazine is, to the best of the ability of
 *  the editors and contributors, truthful and accurate.  When possible,
 *  all facts are checked, all code is compiled.  However, we are not
 *  omniscient (hell, we don't even get paid).  It is entirely possible
 *  something contained within this publication is incorrect in some way.
 *  If this is the case, please drop us some email so that we can correct
 *  it in a future issue.
   Phrack is a compendium of knowledge,
 *  wisdom, wit, and sass.  We neither advocate, condone nor participate
 *  in any sort of illicit behavior.  But we will sit back and watch.
 *
 *
 *  Lastly, it bears mentioning that the opinions that may be expressed in
 *  the articles of Phrack Magazine are intellectual property of their
 *  authors.
 *  These opinions do not necessarily represent those of the Phrack Staff.
 */

                      ----( Contact )----

       <  Editors           : staff[at]phrack{dot}org   >
       >  Submissions       : staff[at]phrack{dot}org   <
       <  Commentary        : loopback[@]phrack{dot}org >
       >  Phrack World News : pwned[at]phrack{dot}org   <

    Submissions may be encrypted with the following PGP key:
    (Hint #1: Always use the PGP key from the latest issue)
    (Hint #2: ANTISPAM or it didn't happen)

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PHRACK

mQGiBEucoWIRBACFnpCCYMYBX0ygl3LrH+WWMl/g6WZxxwLM2IT65gXCuvOEbLHR
/OdZ5T7Z6sO4O5b0EWkk5pa1Z8egNp44+Fn+ExI78cv7ML9ffw1WEAS+raQwvN2w
0WUsfztWHZqPf4HMefX92pv+1kVcio/b0aRT5lRbvD7IdYLrtYb0V7RYGwCgi6Or
dJ5iN+YVDMx8lkUICI8kPxcD/1aHZqCzFx7lI//4OtZQN0ndP1OEH+C7GDfYWi4P
DcLNlF812h1qyJf3QCs93PQR+fu7XWAIyyo5rLHpFfuU29ZZH1Oe0VR6pLJTas2Z
zXNdU48Bhj1uf4Xv0NaAYlQ5ffIJ4a37uIKYRn28sOwH/7P8VGD7K7EZn3MMyewo
aPPsA/4ylQtKkaPB9iTKUlimy5ZZorPwzhNliEbIanCGfePgPz02QMG8gnId40/o
luE0YK1GnUbIMOb6LzI2A5EuQxzGrWzDGOM3uLDLzJtBCg8oKFrUoRVu1dnPEqc/
NQzRYjRK8R8DoDa/QZgyn19pXx4oQ3tAldI4dAQ022ajUhEoobQfUGhyYWNrIFN0
YWZmIDxzdGFmZkBwaHJhY2sub3JnPohgBBMRAgAgBQJLnKFiAhsDBgsJCAcDAgQV
AggDBBYCAwECHgECF4AACgkQxgxUfYgthE7RagCeL/XirVrcUzgKBrJGcvo0xjIE
YlkAoIBqC2GuYJrXxPO/KaJtXglJjd7zuQQNBEucoWIQEADrU+2GAZbWbTElblRp
/MyoUNHm0gxOo7afqVdQe8epub/waQD1bnE+VucI7ncmQWUdD0qkkyzaXlFDlvId
LYh/dMu4/h+nTyuCLNqoycqvf1k8Dax6QOADq0BZlM5lGTL6VOBnCitWCvgYCmLO
aPO1bacJlNx0/cpWKe+YELlZss7Q+o4SBvDOyX8B78eEs62dbRAudubFQ/tjQd3z
cXZOSli9Du9DAa2vzk8tq1c6RAs0NY4KxBu+6VW/lxvGt3iNRlFQAdya6Kx3fhog
zVjkt3OOgNDJ6u/9zYbMbtjtoFqSIJDR4DhZ9NbS57nuTkJqh0GDVOtxfKcc8QxH
wyYiH47M9znHFtHHvT0PzGc2Fl8s3EUFvlXZUW3ikcFbkyqTgnseqv5k9YQ8FDHX
IvBVpj8nqLi3CBADy8z2gy5r4TryV3sfOlTT40r0GtiG3Weeb0wuMj5+hr303zgN
/aH+ps8JvL0TeyXjsDMcTCF1fHSIxPJouSWjOkFMrumAg/rikdn3+dPCCowcLKvQ
isYC60yKEhcYvUDiKKzXrGyM/38Kp/73RA9ZLQ3VjCSX550UCU46hF6u6Qzbd5Jk
T8WesPYqz4jpPzlF1MbaVki4+g5myTR8y1IIarX08mk6l+1YZyjjzmlhKyhdaIiI
QY4uv3EYYFDHiyd0/3ZBfkz62wADBQ//bVf698IFhoLHeCG3USyl/rHyjVUatsCx
ZCwPlWEGzR+RP3XdqwoeFZNA4hXYy3Qr1vJSytbCRDYOK2Rp3Eos1Gncqp3KbUhQ
ZRBxGNbhskZ7VHOvBHIIZ7QU3TDnWLDlWs9oha8zv9XWEmaBmCjBtmRwunphwdv2
O7JpqLbW45l/WAas6CuRi+VxXllQPM2nKX9JwzyWlvnU3QayO+JJwH5bfeW0Wz53
wqMBJz9hvVaClfAzwEnPnWQxxgA6j7S9AuEv7NRLZsC6nHyGwB7vFfL4dCKt4cer
gYOk5RjhHVNuLJSLhVWRfcxymPRKg07harb9adrPcjJ7fCKXN1oPCcacG0O6vcTb
k58MTzs3CShJ58iqVczU6ssGiVNFmfnTrYiHXXvo/+36c+TizwoXJD7CNGDc+8C0
IxKsZbxgvpFuyRRwrzr3PpecY0I2cWZ7wN3WtFZkDi5OtsIKTXHOozmddhAwxqGK
eURB/yI/4L7t2Kh2EaVOyRbXNa4hwPbqbFiofihjKQ1fFsYCUUW0CAOaXu14QrrC
IepRMQ2tabrYCfyNuLL3JwUFKinXs6SrFcSiWkr9Cpay7Ozx5QosV8YKpn6ojejE
H3Xc0RNF/wjYczOSA6547AzrnS8jkVTV2WIJ5g1ExvSxIozlHU5Dcyn5faftz++y
ZMHT0Ds1FMGISQQYEQIACQUCS5yhYgIbDAAKCRDGDFR9iC2ETsN0AJ9D3ArYTLnd
lvUoDsu23bN4bf7gHwCfUGDsUSAWE/G7xQaBuB50qXecJPo=
=cK7U
-----END PGP PUBLIC KEY BLOCK-----

|=[ EOF ]=---------------------------------------------------------------=|


⚠ Bofrost.lu has degraded performance

In f1381df, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1120 ms

Resolved: Bofrost.lu performance has improved in df13a4c after 6 minutes.


Stackoverflowerror -  when using stash parameter in jenkins pipeline jobs

Jenkins and plugins versions report

Environment

Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?
using kubernetes jenkins hosted on AWS
jenkins version -  jenkins/jenkins:2.426.1
Reproduction steps
stashedFile (name: 'Add_file')
Expected Results
After adding the parameter in jenkins file and then enabled with buildwithparameters
click on build button, not running anything,simply throwing white page
Actual Results
returning stackoverflow errror in jenkins job
io.jenkins.plugins.file_parameters.StashedFileParameterValue.buildEnvironment(StashedFileParameterValue.java:70)
at hudson.model.ParametersAction.buildEnvironment(ParametersAction.java:143)
at hudson.model.Run.getEnvironment(Run.java:2434)
Anything else?
No response
Are you interested in contributing a fix?
No response

I am interested in contributing if you guide me on how to do that

@jglick could you guide us on how to solve the issue

It is not apparent from the description what the repeating stack segment actually is.

@jglick thanks for replying and appreciate your time and effort
they are three steps to reproduce the issue and shared the screenshot as well

added the Stashed File Parameter parameter in the jenkins pipeline  by enabling the "project is parameterised"

Click on build with parameters button, and then click on build of jenkins job

followed that, it showed the white screen

the repeating stack error in log are attached to see more about ir
jenkins-master (2).txt

ERROR logs are attached in file

@jglick hoping attached all required files

org.jenkinsci.plugins.workflow.job.WorkflowRun.getEnvironment(WorkflowRun.java:519)
org.datadog.jenkins.plugins.datadog.model.BuildData.<init>(BuildData.java:150)
org.datadog.jenkins.plugins.datadog.logs.DatadogTaskListenerDecorator.<init>(DatadogTaskListenerDecorator.java:49)
org.datadog.jenkins.plugins.datadog.logs.DatadogTaskListenerDecorator$Factory.of(DatadogTaskListenerDecorator.java:82)
org.jenkinsci.plugins.workflow.log.TaskListenerDecorator.lambda$apply$3(TaskListenerDecorator.java:164)
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
…
java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
org.jenkinsci.plugins.workflow.log.TaskListenerDecorator.apply(TaskListenerDecorator.java:166)
org.jenkinsci.plugins.workflow.job.WorkflowRun.getListener(WorkflowRun.java:236)
org.jenkinsci.plugins.workflow.job.WorkflowRun$Owner.getListener(WorkflowRun.java:1024)
io.jenkins.plugins.file_parameters.StashedFileParameterValue.buildEnvironment(StashedFileParameterValue.java:70)
hudson.model.ParametersAction.buildEnvironment(ParametersAction.java:143)
hudson.model.Run.getEnvironment(Run.java:2434)
org.jenkinsci.plugins.workflow.job.WorkflowRun.getEnvironment(WorkflowRun.java:519)

probably needs to be fixed in the Datadog plugin. There is no apparent reason why DatadogTaskListenerDecorator would need to look up the BuildData so eagerly. Better report it there. In the meantime, pick one plugin to uninstall.


Update ESLint, add Airbnb eslint config

According #97, but we have to update sources or rules before merge it.
Now eslint src test generates next output:
src/Redux.js
   9:6   error  Assignment to function parameter 'dispatcher'  no-param-reassign
  47:31  error  Unexpected space before function parentheses   space-before-function-paren

src/components/createConnector.js
  34:13  error  Unexpected 'else' after 'return'  no-else-return

src/index.js
  2:7  error  "createRedux" used outside of binding context         block-scoped-var
  3:7  error  "createDispatcher" used outside of binding context    block-scoped-var
  6:7  error  "composeMiddleware" used outside of binding context   block-scoped-var
  7:7  error  "composeStores" used outside of binding context       block-scoped-var
  8:7  error  "bindActionCreators" used outside of binding context  block-scoped-var

src/utils/shallowEqual.js
   6:2   error  Unexpected var, use let or const instead                         no-var
   6:2   error  All "var" declarations must be at the top of the function scope  vars-on-top
   7:2   error  Unexpected var, use let or const instead                         no-var
   7:2   error  All "var" declarations must be at the top of the function scope  vars-on-top
  14:2   error  Unexpected var, use let or const instead                         no-var
  14:2   error  All "var" declarations must be at the top of the function scope  vars-on-top
  15:7   error  Unexpected var, use let or const instead                         no-var
  15:7   error  All "var" declarations must be at the top of the function scope  vars-on-top
  17:43  error  Block must not be padded by blank lines                          padded-blocks
  22:4   error  Unexpected var, use let or const instead                         no-var
  22:4   error  All "var" declarations must be at the top of the function scope  vars-on-top
  23:4   error  Unexpected var, use let or const instead                         no-var
  23:4   error  All "var" declarations must be at the top of the function scope  vars-on-top

src/utils/shallowEqualScalar.js
  11:2  error  Unexpected var, use let or const instead                         no-var
  11:2  error  All "var" declarations must be at the top of the function scope  vars-on-top
  12:2  error  Unexpected var, use let or const instead                         no-var
  12:2  error  All "var" declarations must be at the top of the function scope  vars-on-top
  19:2  error  Unexpected var, use let or const instead                         no-var
  19:2  error  All "var" declarations must be at the top of the function scope  vars-on-top
  20:7  error  Unexpected var, use let or const instead                         no-var
  20:7  error  All "var" declarations must be at the top of the function scope  vars-on-top
  25:4  error  Unexpected var, use let or const instead                         no-var
  25:4  error  All "var" declarations must be at the top of the function scope  vars-on-top
  26:4  error  Unexpected var, use let or const instead                         no-var
  26:4  error  All "var" declarations must be at the top of the function scope  vars-on-top

test/components/connect.spec.js
  50:43  error  Block must not be padded by blank lines  padded-blocks

test/components/provide.spec.js
  41:43  error  Block must not be padded by blank lines  padded-blocks

test/createDispatcher.spec.js
  10:35  error  Block must not be padded by blank lines  padded-blocks

test/createRedux.spec.js
  8:30  error  Block must not be padded by blank lines  padded-blocks

test/getDisplayName.spec.js
  5:35  error  Block must not be padded by blank lines  padded-blocks

test/utils/bindActionCreators.spec.js
  8:39  error  Block must not be padded by blank lines  padded-blocks

✖ 39 problems (39 errors, 0 warnings)

There is 2 ways which we can do:

We can update modules to this rules.
We can temporary disable above rules.

I applied second way - disable some rules by override airbnb-config. We can remove this overrides when we update sources.

We should fix the warnings in the code, not disable rules. That was the point of adopting the airbnb style :)
Can you do that?

We should fix the warnings in the code, not disable rules.

:+1:

Ok, I fixed that all but we still can't apply block-scoped-var rule according this issue:
https://github.com/eslint/eslint/issues/2087

Oh, I found that tests has not been changed. When I tried to do it I found this issue:
https://github.com/eslint/eslint/issues/1416
So totally I disabled two rules which are not working correct with:
a) export ... from ...;
b) decorators
I think we can merge it anyway and enable those rules when ESLint issues has been fixed.

Can you use const whenever it is possible?

Done :)

Please merge the master in (if you haven't already) and squash this into a single commit.
Thanks for all the work!

Any idea why Travis might be failing?

This is in.
Thank you very much!

@gaearon hmm, a colleague of mine had a similar problem today related to sourcemaps.
Error: /home/travis/build/gaearon/redux/test/components/Connector.spec.js: Invalid mapping: {"generated":{"line":80,"column":46},"source":"/home/travis/build/gaearon/redux/test/components/Connector.spec.js","name":null}
    at SourceMapGenerator_validateMapping [as _validateMapping] (/home/travis/build/gaearon/redux/node_modules/babel-core/node_modules/source-map/lib/source-map/source-map-generator.js:275:15)

Re-installing dependencies didn't help but I think he somehow managed to solved it by re-installing node.
No clue what is causing this problem though...

It's was pleasure to help :) I've created new issue for block-scoped-var problem https://github.com/eslint/eslint/issues/2807


fix platform dependent unit tests

fixes #510

Ask Valentin for a Windows laptop! :)
On Tue, Mar 29, 2016 at 4:11 PM, meltsufin<EMAIL_ADDRESS>wrote:

LGTM assuming you tested on a Windows machine.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/gcloud-intellij/pull/557#issuecomment-203079110

As much as I trust the Windows emulator in my head, that's what I did :) Already tested on a win laptop.

@patflynn any comments on this one?

  More static nastiness.  Leave it as is then. Thanks for trying.

LGTM


fix tsm1 for Solaris #4787, passes unit tests now

Added a platform-specific mmap_solaris.go, based on BoltDB's bolt/bolt_unix_solaris.go: https://github.com/boltdb/bolt/pull/411

This supersedes #4788, which was failing on Solaris and probably also broke Windows (even further than it already was).

Great, thanks @fazalmajid! Can you sign the CLA? https://influxdb.com/community/cla.html
I'll get it merged in right after

@pauldix Done, and thanks!

Great, thanks!

Cherry-picked to the 0.9.6. branch.


Unable to Parse PDB (Failing validation)

Describe the bug
Attempting to load any PDB files results in the following exception:
PDB Execution failure of pdb.exe.
This was likely caused by severe execution failure which can occur if executed
on an unsupported platform. It may be neccessary to rebuild the PDB executable
for your platform (see Ghidra/Features/PDB/src).
ghidra.app.util.bin.format.pdb.PdbException: PDB Execution failure of pdb.exe.
This was likely caused by severe execution failure which can occur if executed
on an unsupported platform. It may be neccessary to rebuild the PDB executable
for your platform (see Ghidra/Features/PDB/src).
	at ghidra.app.util.bin.format.pdb.PdbParser.verifyPdbSignature(PdbParser.java:576)
	at ghidra.app.util.bin.format.pdb.PdbParser.processPdbContents(PdbParser.java:554)
	at ghidra.app.util.bin.format.pdb.PdbParser.parse(PdbParser.java:147)
	at pdb.LoadPdbTask$1.analysisWorkerCallback(LoadPdbTask.java:66)
	at ghidra.app.plugin.core.analysis.AutoAnalysisManager$AnalysisWorkerCommand.applyTo(AutoAnalysisManager.java:1677)
	at ghidra.app.plugin.core.analysis.AutoAnalysisManager$AnalysisTaskWrapper.run(AutoAnalysisManager.java:685)
	at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:785)
	at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:664)
	at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:629)
	at ghidra.app.plugin.core.analysis.AnalysisBackgroundCommand.applyTo(AnalysisBackgroundCommand.java:62)
	at ghidra.framework.plugintool.mgr.BackgroundCommandTask.run(BackgroundCommandTask.java:101)
	at ghidra.framework.plugintool.mgr.ToolTaskManager.run(ToolTaskManager.java:315)
	at java.base/java.lang.Thread.run(Thread.java:835)

---------------------------------------------------
Build Date: 2019-Aug-29 0928 EDT
Ghidra Version: 9.1
Java Home: C:\Program Files\Java\jdk-12.0.2
JVM Version: Oracle Corporation 12.0.2
OS: Windows 10 10.0 amd64
Workstation: DESKTOP-SSR8888

To Reproduce
Steps to reproduce the behavior:

Load any PDB file.

Attachments
InheritanceTests.zip
The source for the executable in the attachment is located here
Additional context
Running pdb.exe directly and using createPdbXmlFiles.bat works without issue. Using the debugger I have stepped through to PDBParser.java line 514. The String[] cmd that is being passed to pdb.exe is the following:
cmd[0]: "C:\Users\astre\Documents\ghidra_9.1_DEV\Ghidra\Features\PDB\os\win64\pdb.exe"
cmd[1]: "C:\Users\astre\Documents\cpp\visual_studio\x64\Debug\main.pdb"
cmd[2]: "4d2d0e81-7184-44b2-b42d-0071b129ae9c"
cmd[3]: "00000001"

when running pdb.exe with those arguments it says "WARNING PDB signature does not match." however removing cmd[3] allows it to parse the file without an issue.

Each time the executable is built, the age is incremented. That is the field value of cmd[3]. The GUID is cmd[2]. These two fields are used to validate the correct PDB with the executable. Pdb.exe can be run with or without validation. By leaving out the GUID and age, no validation is done; and it must be doing partial validation if leaving out the age. Using an unmatched PDB can lead to incorrect data types and, more likely, labels being put down at the wrong places.
The part of Ghidra that tries to find the correct PDB needs some work and “might” get confused when there are multiple PDBs that are close matches, but not the correct match. It currently chooses one, and if it fails validation, it doesn’t check the others. Some of the paths that are checked are the location from which the executable was loaded, the download folder used when downloading PDBs from symbol servers, and the location specified in the executable (PE header)—this last location will no longer be checked in the master branch, as of a week or two ago, unless the option to do so is checked. We hope to clean up the searching code soon.
I would suggest moving all of the PDBs from the sorts of folders indicated above and doing a fresh build of the executable to try to get a matching PDB. Another option would be to try to selectively only make one PDB available at a time until the one with the matching age is found, at which point validation should succeed. Another option is to check the box on the PDB analyzer options that relates to checking the PE header specified path.

Related to #198

Interesting. I wonder if it is because I tried using it right after it was created. I noticed the age was one even though it wasn't a day old yet. I will check later if it is valid with the age set to 0.

The age isn’t the number of days. It is just a one-up count. Each time it is built (probably in the presence of an existing PDB or maybe solution file or maybe intermediate link file—I don’t know where it discovers the previous age), the age is incremented.
Here’s what can happen, and it has happened to me. You build the executable and import it to Ghidra. It will note the GUID and age of the PDB—say age is N.  The PDB will also know it’s GUID and age.  Then you happen to rebuild the executable, but don’t reimport it.  A newer PDB is created with the same GUID, but with age N+1. Then if you try to analyze the program in Ghidra, it will look for age N, but only see the PDB with age N+1 and give the error.
Unfortunately, Ghidra is not outputting the most helpful error messages.

@astrelsky Have you investigated whether you had recompiled your executable after it had already been imported to Ghidra, which would have recreated a mismatched PDB for the program already imported?  Have you tried any of the clean-up steps I suggested earlier to try to get a matched PDB?

@astrelsky Have you investigated whether you had recompiled your executable after it had already been imported to Ghidra, which would have recreated a mismatched PDB for the program already imported? Have you tried any of the clean-up steps I suggested earlier to try to get a matched PDB?

This occurs when creating a fresh visual studio project and compiling, deleting the .ghidra directory in %userprofile% (for sanity) and loading it into a fresh ghidra project.

If you eliminate the value from cmd[3] and then look at the first line of XML that is created, you will see the GUID and age of the PDB.  What is the age? I'm not sure if it is supposed to start at 0 or 1.  The value should hopefully give us a clue.

If you eliminate the value from cmd[3] and then look at the first line of XML that is created, you will see the GUID and age of the PDB. What is the age? I'm not sure if it is supposed to start at 0 or 1. The value should hopefully give us a clue.

When I stepped through the debugger it's passing a value of 1

It seems that you hit on something. I’m not at work to check all, but to be clear, I have a couple of questions:
Where are you adding the braces (to the first lin of the XML or to cmd[2])?
What version of Visual Studio are you using to build your target/PDB?
Since you are noting 9.1/master, I’m assuming you built the pdb.exe with the same VS in the previous question... yes?
I don’t see where we have removed the braces in Ghidra, but it could be that commits from 2 months ago have caused this issue. However,  if you are using VS 2019, it could be that VS 2019 changed the GUID in the PDB itself or it could be changes in the DIA or other library methods, such as StringFromGUID2, used in the pdb.exe.

It seems that you hit on something. I’m not at work to check all, but to be clear, I have a couple of questions:
Where are you adding the braces (to the first line of the XML or to cmd[2])?
What version of Visual Studio are you using to build your target/PDB?
Since you are noting 9.1/master, I’m assuming you built the pdb.exe with the same VS in the previous question... yes?
I don’t see where we have removed the braces in Ghidra, but it could be that commits from 2 months ago have caused this issue. However, if you are using VS 2019, it could be that VS 2019 changed the GUID in the PDB itself or it could be changes in the DIA or other library methods, such as StringFromGUID2, used in the pdb.exe.

I inserted the braces directly into pdbGuid in PdbParser.java on line 267 after stepping over it.
After digging a bit I pulled up the program information in ghidra. This is what it looks like.

Should the braces be present in the guid there?
I do have vs2019 installed but made sure to compile both pdb.exe and the test binary with vs2017.
Should I ensuring that the vs 2017 version of msdia140.dll is registered and not the 2019 version?

Ok. I can see that you added the braces to the value stored that supposedly comes from the PE header. I’ll have to look closer tomorrow to see what might have changed, if anything. But this could also mean that a change could have been introduced in the PeLoader. I’ll try to run older versions of Ghidra against newer and track the GUID throughout.
If you have the time and ability to make sure that the 2017 version of msdia140 is registered, that could eliminate one more variable.

Ok. I can see that you added the braces to the value stored that supposedly comes from the PE header. I’ll have to look closer tomorrow to see what might have changed, if anything. But this could also mean that a change could have been introduced in the PeLoader. I’ll try to run older versions of Ghidra against newer and track the GUID throughout.
If you have the time and ability to make sure that the 2017 version of msdia140 is registered, that could eliminate one more variable.

I ran a quick check and it appears the issue is either with pdb.exe or from the registered msdia140.dll I re-registered the vs2017 one last night. Running the pdb.exe from ghidra 9.0.4 loads parses the pdb without the braces but the one from ghidra 9.1 dev does not. I'm currently building ghidra and will try again with the rebuilt ghidra 9.1 pdb.exe now that the vs2017 msdia140.dll is registered.

@astrelsky Thanks for the report back.  Appreciate your drilling in on this. I've been tied up from the beginning of the day, so just going to start looking now.

It might take a little to propagate into master because of recent changes in building and testing of this native code, but I have a branch to fix this issue and a PDB help issue.


pyscan seems to depend on pip

Describe the bug
tool does not work when pip is not on your path
To Reproduce

use e.g. Ubuntu with no pip installed
run pyscan

❯ pyscan
pyscan v0.1.5 | by Aswin S (github.com/aswinnnn)
Failed to execute 'pip list' command. pyscan caches the dependencies from pip with versions to be faster and it could not run 'pip list'. You can turn this off via just using --cache-off [note: theres a chance pyscan might still fallback to using pip]

Note:
Not having a global pip is indeed a very good thing on e.g Ubuntu, as then you completely avoid installing packages into the global site-packages, which could break your Ubuntu installation.
And when you ask how I install packages... When creating a venv, the tool virtualenv also installs pip and setuptools into that environment.

if you read the error, you can see that using the --cache-off flag will turn off the caching at the beginning so im not sure i understand your problem?
The fallback also should not pose a problem as it resorts to pypi.org when a version couldn't be gotten from pip. However I see the point in making pyscan aware of whether pip exists or not beforehand.

so im not sure i understand your problem?

pyscan does not do anything. When I put pip on the path, it at least lists the dependencies...
compare
with pip on path (ignore the error for now - reported in #13)
~/Projects/hypermodern via 🐍 v3.8.10 (xxx)
❯ pyscan
pyscan v0.1.5 | by Aswin S (github.com/aswinnnn)
Found 3 dependencies
pytest : A version could not be detected through source or pip, so retrieving latest version from pypi.org instead.
Failed to make a request to pypi.org:
HTTP status client error (404 Not Found) for url (https://pypi.org/pypi/httpx[http2]%3E=0.23.1/json)
pypi.org error: HTTP status client error (404 Not Found) for url (https://pypi.org/pypi/httpx[http2]%3E=0.23.1/json)

without pip on path
❯ pyscan
pyscan v0.1.5 | by Aswin S (github.com/aswinnnn)
Failed to execute 'pip list' command. pyscan caches the dependencies from pip with versions to be faster and it could not run 'pip list'. You can turn this off via just using --cache-off [note: theres a chance pyscan might still fallback to using pip]

with `--cache-off
❯ pyscan --cache-off
pyscan v0.1.5 | by Aswin S (github.com/aswinnnn)
Found 3 dependencies
Failed to execute 'pip list' command. pyscan caches the dependencies from pip with versions to be faster and it could not run 'pip list'. You can turn this off via just using --cache-off [note: theres a chance pyscan might still fallback to using pip]

Maybe I fail to understand the output and/or the --cache-off function.
I currently do not have access to a single Python project where pyscan would work 100% and outputs something like on the screenshot from your readme.
Could you link to a working project? So I can make sure I understand which issues are from the Python projects, and which from my system setup.

That is extremely weird and something that has never come up in my test cases. Have you tried it with a requirements.txt ? Specifying the versions are optional
I'm AFK at the moment but the reqs i tested against, one had no versions and other one had versions, both didnt fail.
The pypi.org error happens to due to the way the URL is string formatted, somehow the version gets injected into it instead of solely the package name, very weird.

Indeed, requirements.txt + putting pip on path works.
/tmp/test-r
❯ echo requests > requirements.txt

❯ pyscan
pyscan v0.1.5 | by Aswin S (github.com/aswinnnn)
Using requirements.txt/constraints.txt as source...
Found 1 dependencies
requests : A version could not be detected through source or pip, so retrieving latest version from pypi.org instead.
|-| requests [2.31.0] -> No vulnerabilities found.
Finished scanning all found dependencies.

Now that we know this works, it just got even more weirder. Could you show me the content of what pyscan was trying to read from earlier where the 404 errors happened? Im sure something is going wrong somewhere along the parsing process.

The issue which resulted in the 404 is reported in #13 - there is also a link to the pyproject.toml.

theres no parsing done at extract_imports_pyproject() at extractor.rs, i must have forgotten it. Looks like we found the root of the problem


[Suggestion] Allow React to send commands

please will you add a "command" action to React that executes a command as console? this would make it a massively more powerful tool, as you'd be able to trigger e.g. .mcfunction files without having to have a main loop constantly running and testing various values!
the ability to substitute %target_type% with an appropriate value* would be awesome, but in all honesty i'd be very happy to even have the option to have React send commands at all.
*(i.e. to substitute the appropriate UUID for the target %player% , %mob% , %sender% , %attacker% or %tamer%, the %dimension% number, or the x y z for the target %block%)

A "command" action will be added in the next release.
player_log_in=[
	{
		action=server_command
		parameters {
			command="tell %%%player.uuid%%% Hello!"
		}
		conditions {
			side=server
		}
	}
]

the ability to substitute %target_type% with an appropriate value* would be awesome, but in all honesty i'd be very happy to even have the option to have React send commands at all.
*(i.e. to substitute the appropriate UUID for the target %player% , %mob% , %sender% , %attacker% or %tamer%, the %dimension% number, or the x y z for the target %block%)

Instead of simply using %player%, %mob%, and so on, I've added a number of "properties" for each target type. Properties are used in combination with a target, e.g. "%%%mob.name%%%" or "%%%player.uuid%%%".
For example, this:
player_sleep=[
	{
		action=log
		parameters {
			log_name=sleep # Newly added parameter, the log will be saved to logs/react/sleep.log
			message="[%player.name%] (id: [%player.uuid%], position: [%player.position%]) has gone to bed."
		}
	}
]

Produces this:
[26.11.2017-13:57:14] [INFO]: Player735 (id: fd6f2cd7-e2c4-325a-9688-114cce28bfc9, position: [x=-31.301430173440238,y=64.0,z=95.4435380922974]) has gone to bed.`

sorry i haven't seen this sooner - that looks amazing, thank you! i checked r/feedthebeast and you don't seem to have posted a link to this, would you like to/would it be ok if i did? i think a lot of people there would appreciate it too! :)

I have added the following "target properties":
Mobs:

name (e.g. Wolf, custom name, or username)
uuid (e.g. 1b284948-a0e9-4f53-9ecd-dc2d9470934f)
type (e.g. minecraft:zombie)
position (e.g. [x=-522,y=69,z=418])
x_position (e.g. -522)
y_position (e.g. 69)
z_position (e.g. 418)

Players:

ip (e.g. <IP_ADDRESS> in multiplayer, or local in singleplayer)
All target properties for mobs.

Blocks:

id (e.g. minecraft:stone)
position (e.g. [x=-522,y=69,z=418])
x_position (e.g. -522)
y_position (e.g. 69)
z_position (e.g. 418)

Miscellaneous:

damage_source.name
damage_amount
message (chat-related events)
hand
command
command_arguments.list

Should anything else be added?

i checked r/feedthebeast and you don't seem to have posted a link to this, would you like to/would it be ok if i did?

I did mention it in my 1.12 update post. Feel free to post it again, though.

that's wonderful, that really is!

Should anything else be added?
this is my fault, i should've remembered it when i first made the issue; uuid probably wants to be available as uuid_most and uuid_least too, as that's how they're stored in nbt tags, and minecraft commands don't have any way of natively using the uuid as it's commonly expressed :/

the current HP and maybe armour for mobs would likely be very handy. if you feel like it, you could (is "recursively" the right word here?) add the mob/block target properties of whatever the mob in question is targeting.
so potentially a script could use %%%mob.target.position%%% to occasionally set fires or place particles where a mob is looking. or maybe even %%%mob.target.target.position%%% - i can see that one being useful in .mcfunction scripts, f'rinstance, so checking if %%%mob.uuid%%% == %%%mob.target.target.uuid%%% would let you figure out if two entities are mutually targeting each other. in combination with e.g. fake players, being able to "daisy-chain" targeting could be powerful.

I did mention it in my 1.12 update post. Feel free to post it again, though.
i think this update is worth mentioning, i reckon a lot of packmakers will absolutely love the functionality you're including! thank you again! =)

I will be releasing the next version later today.

the current HP and maybe armour for mobs would likely be very handy.

Added.

this is my fault, i should've remembered it when i first made the issue; uuid probably wants to be available as uuid_most and uuid_least too, as that's how they're stored in nbt tags, and minecraft commands don't have any way of natively using the uuid as it's commonly expressed :/

Are you sure? I seem to be able to use /kill with my UUID...

if you feel like it, you could (is "recursively" the right word here?) add the mob/block target properties of whatever the mob in question is targeting.

That would require too much work, I'm afraid. Maybe later.

Are you sure? I seem to be able to use /kill with my UUID...
oh, sweet, then i'm totally wrong! the wiki gave me the opposite impression but it's all good =)
That would require too much work, I'm afraid. Maybe later.
no, i totally understand, that really was an "as long as i'm dreaming" kinda thing! seriously, thank you ever so much again, the extra scope you've just given me and other packmakers (those of us who can't code anyway) is amazing! <3

Version 1.1.0 has been released on GitHub, it will be uploaded to CurseForge as soon as I've finished the changelog.


Sqitch: Set up database migrations in prod

Migrated the flyway files into sqitch files.
Change-Id: Iac79479dfdd5b86366246d5134ac6af28e657fa1

Code Review comments can be found at https://gerrithub.io/q/Iac79479dfdd5b86366246d5134ac6af28e657fa1


SAML UI clarification

Under Username Attribute

Clarified where to access to the username attribute field

Hello @cwarnermm,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.


Add generic viewset for handling all CRUD in one view

add a decorator for defining custom methods of viewset


Feature Request: use default directory if not specified

Now ATAC (version 0.15.1) must be given a working directory on startup.

IMHO, a tui application can use the default directory specified by the OS, i.e:

OS
config directory
cache directory

Linux
/home/alice/.config/barapp
/home/alice/.cache/barapp

Windows
C:\Users\Alice\AppData\Roaming\Foo Corp\Bar App\config
C:\Users\Alice\AppData\Local\Foo Corp\Bar App\cache

MacOS
/Users/Alice/Library/Application Support/com.Foo-Corp.Bar-App
/Users/Alice/Library/Caches/com.Foo-Corp.Bar-App

(Suppose the user name is Alice, the organization name is Foo Corp and the application name is Bar App).
All this can be easily handled by the directory crate:
[dependencies]
directories = "5"

// these are just examples, there must be some other much more better options
// and if you want the `ORGANIZATION` be present on Linux, some thing like `#[cfg(target_os = "linux")]` can be used
pub const APP_NAME: &str = "ATAC";
pub const QUALIFIER: &str = "fr";
pub const ORGANIZATION: &str = "Julien";

let project_dir = directories::ProjectDirs::from(QUALIFIER, ORGANIZATION, APP_NAME).unwrap();
let config_dir = project_dir.config_dir();
let cache_dir = project_dir.cache_dir();
let mut log_dir = cache_dir.to_owned();
log_dir.push("logs");

What kind of knowledge do you need? I'm very glad to help but I lack experience and necessary knowledge. I saw some links on the document page of the directories crate which might help you.

I do not understand how the directory gets created, does I need to always try to create the directory when using the app ? Or does it needs something specific when installing?
Will it work with the ATAC_MAIN_DIR variable or do I have to change the way it works?
Thanks in advance

I think the directories crate doesn't automatically create the project directory for us. So I suggest that ATAC create it if the directory argument was not provided, the ATAC_MAIN_DIR env variable was not provided and the project directory was not found.
I draw a flow chart to make it clear:

IMHO, a tui application can use the default directory specified by the OS, i.e:\n\nOS\tconfig directory\tcache directory\nLinux\t/home/alice/.config/barapp\t/home/alice/.cache/barapp\nWindows\tC:\Users\Alice\AppData\Roaming\Foo Corp\Bar App\config\tC:\Users\Alice\AppData\Local\Foo Corp\Bar App\cache\nMacOS\t/Users/Alice/Library/Application Support/com.Foo-Corp.Bar-App\t/Users/Alice/Library/Caches/com.Foo-Corp.Bar-App\n(Suppose the user name is Alice, the organization name is Foo Corp and the application name is Bar App).\n\nAll this can be easily handled by the directory crate:\n\n[dependencies]\ndirectories = "5"\n// these are just examples, there must be some other much more better options\n// and if you want the ORGANIZATION be present on Linux, some thing like #[cfg(target_os = \"linux\")] can be used\npub const APP_NAME: &str = "ATAC";\npub const QUALIFIER: &str = "fr";\npub const ORGANIZATION: &str = "Julien";\n\nlet project_dir = directories::ProjectDirs::from(QUALIFIER, ORGANIZATION, APP_NAME).unwrap();\nlet config_dir = project_dir.config_dir();\nlet cache_dir = project_dir.cache_dir();\nlet mut log_dir = cache_dir.to_owned();\nlog_dir.push("logs");

Please also consider that in addition of that, people might expect to respect XDG_CONFIG_HOME and XDG_DATA_HOME
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
Does this crate respect that?

IMHO, a tui application can use the default directory specified by the OS, i.e:\n\nOS\tconfig directory\tcache directory\nLinux\t/home/alice/.config/barapp\t/home/alice/.cache/barapp\nWindows\tC:\Users\Alice\AppData\Roaming\Foo Corp\Bar App\config\tC:\Users\Alice\AppData\Local\Foo Corp\Bar App\cache\nMacOS\t/Users/Alice/Library/Application Support/com.Foo-Corp.Bar-App\t/Users/Alice/Library/Caches/com.Foo-Corp.Bar-App\n(Suppose the user name is Alice, the organization name is Foo Corp and the application name is Bar App).\n\nAll this can be easily handled by the directory crate:\n\n[dependencies]\ndirectories = "5"\n// these are just examples, there must be some other much more better options\n// and if you want the ORGANIZATION be present on Linux, some thing like #[cfg(target_os = \"linux\")] can be used\npub const APP_NAME: &str = "ATAC";\npub const QUALIFIER: &str = "fr";\npub const ORGANIZATION: &str = "Julien";\n\nlet project_dir = directories::ProjectDirs::from(QUALIFIER, ORGANIZATION, APP_NAME).unwrap();\nlet config_dir = project_dir.config_dir();\nlet cache_dir = project_dir.cache_dir();\nlet mut log_dir = cache_dir.to_owned();\nlog_dir.push("logs");

Please also consider that in addition of that, people might expect to respect XDG_CONFIG_HOME and XDG_DATA_HOME
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
Does this crate respect that?

I'm not quite sure, maybe it does according to its comment:

Closes by https://github.com/Julien-cpsn/ATAC/releases/tag/v0.18.0


Add simple EvAPI and extend EvManager with simplistic SoC calculation

Describe your changes
Issue ticket number and link
Checklist before requesting a review

[x] I have performed a self-review of my code
[ ] I have made corresponding changes to the documentation
[x] I read the contribution documentation and made sure that my changes meet its requirements

Maybe we can combine the new ev_manager interface with the existing car_simulator interface. I see no problem with  moving the cmds and var from the car_simulator interface to the ev_manager interface.

I am not sure why I was added into this code review. @hikinggrass This does not seem to touch Rust or Bazel?

I am not sure why I was added into this code review. @hikinggrass This does not seem to touch Rust or Bazel?

Doesn't touch rust or bazel, review request were triggered by accident from a botched merge of main into this branch. I've removed the accidentally added reviewers again


[master] Upgrade to latest dependencies

Cron. -knative-prow-robot
/cc knative-sandbox/networking-wg-leads
/assign knative-sandbox/networking-wg-leads
Produced via:
./hack/update-deps.sh --upgrade --release v0.21
./hack/update-codegen.sh

Details:
bumping knative.dev/networking e223a89...4751606:
  > 4751606 upgrade to latest dependencies (# 335)
  > 07536a6 Move RewriteHost conformance tests to Beta (# 334)
bumping knative.dev/pkg 5bb97df...75d66b5:
  > 75d66b5 preserve the stable webhook logger names we had before (# 1994)
  > 22f4898 upgrade to latest dependencies (# 1990)

/lgtm

/lgtm


Java 8 is not supported

Describe the bug
As mentioned in the official documentation, fixture-monkey should support Java 8 / kotlin 1.8 but I am getting issues while using in a project with Kotlin 1.8.
Your environment

com.navercorp.fixturemonkey:fixture-monkey-starter-kotlin:1.0.5
kotlinVersion=1.8.22
java 1.8 & JRE 17

Steps to reproduce
*Use the above environment setup
Expected behaviour
gradle lockdown should work without errors
Actual behaviour
Gradle lockdown failed with the below error

Execution failed for task ':pug-client:lockdown'.
Could not resolve all dependencies for configuration ':pug-client:tmp-lockdown-check-testRuntimeClasspath'.
Could not resolve com.navercorp.fixturemonkey:fixture-monkey-starter-kotlin:1.0.5.
Required by:
project :pug-client > project :pug-core-testutils
No matching variant of com.navercorp.fixturemonkey:fixture-monkey-starter-kotlin:1.0.5 was found. The consumer was configured to find a runtime of a library compatible with Java 8, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm' but:
- Variant 'apiElements' capability com.navercorp.fixturemonkey:fixture-monkey-starter-kotlin:1.0.5 declares a library, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm':
- Incompatible because this component declares an API of a component compatible with Java 11 and the consumer needed a runtime of a component compatible with Java 8
- Variant 'javadocElements' capability com.navercorp.fixturemonkey:fixture-monkey-starter-kotlin:1.0.5 declares a runtime of a component, and its dependencies declared externally:
- Incompatible because this component declares documentation and the consumer needed a library
- Other compatible attributes:
- Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
- Doesn't say anything about its target Java version (required compatibility with Java 8)
- Doesn't say anything about its elements (required them packaged as a jar)
- Doesn't say anything about org.jetbrains.kotlin.platform.type (required 'jvm')
- Variant 'runtimeElements' capability com.navercorp.fixturemonkey:fixture-monkey-starter-kotlin:1.0.5 declares a runtime of a library, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm':
- Incompatible because this component declares a component compatible with Java 11 and the consumer needed a component compatible with Java 8
- Variant 'sourcesElements' capability com.navercorp.fixturemonkey:fixture-monkey-starter-kotlin:1.0.5 declares a runtime of a component, and its dependencies declared externally:
- Incompatible because this component declares documentation and the consumer needed a library
- Other compatible attributes:
- Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
- Doesn't say anything about its target Java version (required compatibility with Java 8)
- Doesn't say anything about its elements (required them packaged as a jar)
- Doesn't say anything about org.jetbrains.kotlin.platform.type (required 'jvm')

@praveenfun2
Thank you for reporting an issue.
It would be fixed in 1.0.7.
I'll let you know when it is published.

Unfortunately, our organization uses a private repository & this snapshot is not available there. Will wait for the release. Thanks.

@praveenfun2
Oh, I see. 1.0.7 is released.

Seems to be working now..!!

This can be closed


Update firestore rules for emulator

Change Summary
Updates Firestore rules for emulator to match the deployed rules, to stop whoever keeps deleting my rules from Firebase deployment.
Change Form

[ ] The pull request title has an issue number
[ ] The change works by "Smoke testing" or quick testing
[ ] The change has tests
[ ] The change has documentation

Other Information
Stop deleting my rules.

The git diff is a little messy, what's actually changing between main and this PR? I'm wondering if the current version is fine, but it just needs to be deployed?
// main
  match /databases/{database}/documents {
    match /users/{userId} {
      match /contacts/{visitId} {
        allow read: if isOwner(userId);
        allow write: if isOwner(userId) && isValidContact(request.resource.data);
      }

      match /visits/{visitId} {
        allow read: if isOwner(userId);
        allow write: if isOwner(userId) && isValidVisit(request.resource.data);
      }

      match /info {
        allow read: if isOwner(userId);
        allow write: if isOwner(userId) && isValidContact(request.resource.data);
      }

      allow read: if isOwner(userId);
      allow write: if isOwner(userId) && isValidUser(request.resource.data);
    }

    match /incidents/{document=**} {
      allow create: if isSignIn();
      allow read: if isAdmin();
      allow update, delete: if false;
    }

    match /roles/{userId} {
      allow read: if isAdmin() && isOwner(userId);
      allow write: if false;
    }

    match /vet_concerns/{concern} {
      allow create: if isSignIn() && isValidVetConcern(request.resource.data);
      allow read: if isAdmin();
      allow update, delete: if false;
    }
  }

This might be my bad.
I deployed the firestore rules when I was working on #209 to test something, my branch was a little behind main and must have missed your changes to the rules.
It should be fixed now, I've pulled from main and deployed the rules again.


Revert direct api hotfix

api.utdnebula.com is back up we we can revert these 2 commits
no rush to make another PR to merge this into main but it should be done at some point

Will batch merge into main sometime in the near future


Raise if an AOT compiled function is called with arguments that do not match the signature

Following on from https://github.com/numba/numba/issues/2755#issuecomment-366109388.
Running this script to compile a module nbmod with AOT function func1:
from numba import njit
from numba.pycc import CC

cc = CC('nbmod')

@cc.export('func1',  'f8[:,:](f8[:,:])')
@njit
def func1(x):
    return x + 1.

if __name__ == "__main__":
    cc.compile()

and then running this script making use of the compiled module:
import nbmod
import numpy as np

x = np.arange(12).reshape(4, 3)
print(nbmod.func1(x))
print(nbmod.func1(x.astype(np.float64)))

gives this:
[[ 1.  1.  1.]
 [ 1.  1.  1.]
 [ 1.  1.  1.]
 [ 1.  1.  1.]]
[[  1.   2.   3.]
 [  4.   5.   6.]
 [  7.   8.   9.]
 [ 10.  11.  12.]]

The first result is incorrect due to the wrong data type used in the input. The compiled function should raise an exception if the type of the arguments presented at run time do not match those declared when the function was compiled.

Please add a HUGE warning in the AOT compilation docs about this until it is fixed or mitigated somehow.

This one is almost 2 years old, wonder if there were any changes to AOT warnings/exceptions?

@aldanor None that I recall, patches are welcomed.


Adds test for group members function for non group creator client

Once https://github.com/xmtp/libxmtp/pull/781 merges this test should start passing

Closed in favor of https://github.com/xmtp/libxmtp/pull/794


Error reading ZIP-file while building the code

I am trying to build the code for Overgrowth with Debug|64x configuration. Earlier, before main menu, I got the error about missing icon-online.png file, but that issue can be neglected.
When I'm trying to start the first level, "White Flags", or continue it, after minutes of getting data I receive an error saying the program couldn't read data from ZIP-file. The screenshot with the error and traceback are below:

I suppose something fishy is going in the function reading the ZIP-file. The ZIP is present in the folder. Are there any options to resolve the issue besides the manual unzipping or smth?

Getting the same failure as well as continuing from the missing icon. Did you manage to find a fix?

I switched to internal_testing on Steam and that particular issue was resolved. Now it's showing other similar issues, but also even just playing from Steam is not working. I take it internal_testing is actually not in a working state at the moment?
Is there any way to get this to work on Windows with Steam?

Similar scenario, working on Windows. More info that I've uncovered:
Loading White Flags fails on both Debug/64 and Release/64, somewhere during or after converting textures in converttexture.cpp, regardless of whether or not the game was started with a blank cache:
[i][__]:converttexture.cpp:  50: Converting D:/Steam/steamapps/common/Overgrowth/Data/Textures/Thumbnails/og_story/smallest_12_canyon_ambush.jpg to C:/Users/tfsch/Documents/Wolfire/Overgrowth/Data/Textures/Thumbnails/og_story/smallest_12_canyon_ambush.jpg_converted.dds by way of C:/Users/tfsch/Documents/Wolfire/Overgrowth/Data/Temp/conversion0.dds
[i][__]:converttexture.cpp: 120: Conversion completed
[i][__]:converttexture.cpp:  50: Converting D:/Steam/steamapps/common/Overgrowth/Data/Textures/Thumbnails/og_story/smallest_13_rat_slavers.jpg to C:/Users/tfsch/Documents/Wolfire/Overgrowth/Data/Textures/Thumbnails/og_story/smallest_13_rat_slavers.jpg_converted.dds by way of C:/Users/tfsch/Documents/Wolfire/Overgrowth/Data/Temp/conversion0.dds
[i][__]:converttexture.cpp: 120: Conversion completed
[i][__]:   zip_util.cpp: 412: 0
[i][__]:   zip_util.cpp: 413: 20859790
[i][__]:      error.cpp: 182: Displaying message: Error, Error reading from UnZip file
[i][__]:      error.cpp: 183: No stacktrace available on this platform

Sandbox levels like Red Shards can be loaded on either debug or release, but only with a blank cache; attempting to restart and load the same level, or even just quitting to the main menu and reloading results in another failure, this time with the nav-mesh:
[i][__]:    navmesh.cpp: 678: Found:C:/Users/tfsch/Documents/Wolfire/Overgrowth/Data/LevelNavmeshes/Project60/4_red_hills.nav.xml
[i][__]:    navmesh.cpp: 685: Found:C:/Users/tfsch/Documents/Wolfire/Overgrowth/Data/LevelNavmeshes/Project60/4_red_hills.nav.obj
[i][__]:    navmesh.cpp: 692: Found Zip:C:/Users/tfsch/Documents/Wolfire/Overgrowth/Data/LevelNavmeshes/Project60/4_red_hills.nav.zip
[i][__]:    navmesh.cpp: 833: Navmesh: Adding mesh to sample...
[i][__]:   zip_util.cpp: 412: 0
[i][__]:   zip_util.cpp: 413: 959888
[i][__]:      error.cpp: 182: Displaying message: Error, Error reading from UnZip file
[i][__]:      error.cpp: 183: D:\SourceCode\repos\C++\overgrowth\Source\Utility\stacktrace.h(70)
D:\SourceCode\repos\C++\overgrowth\Source\Internal\error.cpp(183)
D:\SourceCode\repos\C++\overgrowth\Source\Internal\error.cpp(54)
D:\SourceCode\repos\C++\overgrowth\Source\Internal\zip_util.cpp(420)
D:\SourceCode\repos\C++\overgrowth\Source\Internal\zip_util.cpp(445)
D:\SourceCode\repos\C++\overgrowth\Source\AI\navmesh.cpp(843)
D:\SourceCode\repos\C++\overgrowth\Source\AI\navmesh.cpp(705)
D:\SourceCode\repos\C++\overgrowth\Source\Main\scenegraph.cpp(1220)
D:\SourceCode\repos\C++\overgrowth\Source\XML\level_loader.cpp(482)
D:\SourceCode\repos\C++\overgrowth\Source\Main\engine.cpp(5524)
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.32.31326\include\type_traits(1503)
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.32.31326\include\functional(684)
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.32.31326\include\functional(1962)
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.32.31326\include\functional(1999)
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.32.31326\include\type_traits(1479)
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.32.31326\include\thread(56)
Couldn't get line numbers. Possibly an external lib
Couldn't get line numbers. Possibly an external lib
Couldn't get line numbers. Possibly an external lib

The zip_util: 412 and 413 lines are debug lines that I've added that print out the version and the uncompressed_size of the zip file, implying that the outer file itself is being loaded at least somewhat properly. Investigating the cache files themselves, they seem to be a zip file contained within another zip file; the outermost zip file can be opened to reveal the contents, but the internal zip file can't seem to be opened neither by Windows nor 7zip. Is this internal file supposed to be a zip file, or is it some other internal format that gets decoded by Overgrowth?
Based on the fact that you can't interpret the files with an external program, that seems to imply to me that there might be problems with the saving in conjunction with the loading of the zip files. Does minizip have any way to query save/load errors?

Damn didnt know nice explanation,i hope there will be a fixed dropped soon so i can start testing internal testing

The more I look at this issue the stranger it becomes. It seems to actually be an issue with zlib, or at least the way that minizip interfaces with it. The faulty code is in zip_util.cpp under UnZipFile::ExtractAll, which when boiled down looks like this:
unzGoToFirstFile(uf);
do {
    int result;
    char filename_buf[256];

    // This succeeds (though technically it can also fail and should probably be checked as well)
    unz_file_info file_info;
    unzGetCurrentFileInfo(uf, &file_info, filename_buf, 256, NULL, 0, NULL, 0);

    // bookkeeping omitted

    // This is what fails
    // Before, this function wasn't checked for success, which I've changed like so
    result = unzOpenCurrentFile(uf);
    if (result != UNZ_OK) {
        FatalError("Error", "Unable to open current file (Error code: %d)", result); // returns -2
    }

    int bytes_read = 0;
    do {
        // Of course, this then fails since there is no open file to read from
        bytes_read = unzReadCurrentFile(uf, scoped_buf.ptr, size_buf);
        if (bytes_read < 0) {
            FatalError("Error", "Error reading from UnZip file (Error code: %d)", bytes_read); // returns -102
        } else if (bytes_read > 0) {
            // Perform normal operations
        }
    } while (bytes_read > 0);
}

unzOpenCurrentFile returns -2, which is peculiar in it's own right, since it means that this isn't a minizip error but rather a zlib error, specifically a Z_STREAM_ERROR. Inspecting the body of unzOpenCurrentFile in unzip.c, the only place that a -2 error code can ever be returned is in this section:
    if ((s->cur_file_info.compression_method==Z_BZIP2ED) && (!raw))
    {
#ifdef HAVE_BZIP2 // This is disabled on my setup, removing for brevity
      // This area _could_ return a -2 error code as well, just not under my current build
#else
      pfile_in_zip_read_info->raw=1;
#endif
    }
    else if ((s->cur_file_info.compression_method==Z_DEFLATED) && (!raw))
    {
      pfile_in_zip_read_info->stream.zalloc = (alloc_func)0;
      pfile_in_zip_read_info->stream.zfree = (free_func)0;
      pfile_in_zip_read_info->stream.opaque = (voidpf)0;
      pfile_in_zip_read_info->stream.next_in = 0;
      pfile_in_zip_read_info->stream.avail_in = 0;

      err=inflateInit2(&pfile_in_zip_read_info->stream, -MAX_WBITS);
      if (err == Z_OK)
        pfile_in_zip_read_info->stream_initialised=Z_DEFLATED;
      else
      {
        //printf("%d\n", err); // including this here does confirm that this is the source of the -2 code
        TRYFREE(pfile_in_zip_read_info);
        return err;
      }
    }

So the actual culprit seems to be inflateInit2. The zlib manual suggests that this particular error is caused "if a parameter is invalid, such as a null pointer to the structure." I've checked both pfile_in_zip_read_info and pfile_in_zip_read_info->stream, and neither are null... changing MAX_WBITS doesn't seem helpful either. Was there any recent changes to zip_util.cpp, minizip or zlib that could explain this read failure?
I investigated the saving code of the navmesh to make sure I didn't see anything funky, and all seems to be in order; I was able to switch back to a non-beta version of Overgrowth and load the cache files generated by internal_testing, which shows that there's only really a problem with getting the data out from the zip files once their loaded. Maybe this is a Windows-specific error?

Maybe this is a Windows-specific error?

Tested on Ubuntu LTS 20.04 with my fork, and lo and behold the issue is magically resolved. I suspected that this was because the Ubuntu build seems to use the OS version of zlib (1.2.11) instead of the prebuilt Windows one in Libraries (1.2.7), so I tried building a set of updated Windows dll and lib files for version 1.2.11 to see if that fixes it.
The answer: No! Still returns a -2 error code on unzOpenCurrentFile... though it could be that I just messed up royally somewhere along the way updating the library. The only other avenue I have at this point is that gzip seems to include it's own 1.2.12 version of zlib in addition to the 1.2.7 one provided alongside; you can verify this by adding:
LOGI << ZLIB_VERSION << std::endl; // "1.2.7"
LOGI << zlibVersion() << std::endl; // "1.2.12"

Maybe there's some weird conflict here?
@autious @feliwir @Conan-Kudo
Do any of you guys have some insight on why internal_testing fails while the non-beta branch has no trouble on Windows?

No, this is a new bug to me. Thanks for doing a detailed investigation of it though, so far you've managed to find some really helpful info.

I talked to Max about it a bit internally. This is due to the upgrade to libfreetype. It uses zlib internally, and caused a ripple effect in minizip. This is what is causing the internal error that results in the error code when trying to load the navmesh zip file.
Going to need to figure out how to configure these two libraries to disentangle how they use zlib. I gave it a shot myself, but only very briefly. I am not an expert at configuring these libraries, so I was unable to get them to do the right thing. Someone who is more familiar, or has more time to go root through config documentation may be able to resolve this.

I think I've finally figured it out, primarily to @shinymerlyn's insight. By default on Windows, Freetype cannot find zlib, so it defaults to it's internal version, which then conflicts with the binary distribution provided in the Libraries folder (zlib1.2.7). However, if you coerce Freetype to load that 1.2.7 binary (so that only one version of zlib is being used), as far as I can tell this entirely fixes the problem. The following is my cursed hack:
# Starting at line 270 of Overgrowth's CMakeLists.txt:
ADD_SUBDIRECTORY(../Libraries/zstd-1.5.0/build/cmake zstd)
IF(WIN32)
    # Manually specify the location of zlib
    GET_FILENAME_COMPONENT( ZLIB_INCLUDE "../Libraries/zlib1.2.7/include" ABSOLUTE )
    GET_FILENAME_COMPONENT( ZLIB_LIBRARY "../Libraries/zlib1.2.7/lib/x64/zlib.lib" ABSOLUTE )
ENDIF()
ADD_SUBDIRECTORY(../Libraries/freetype-2.12.1 freetype)

We have to use get_filename_component to get the absolute paths because using local paths will result in an error. It also might be prudent to have the option FT_REQUIRE_ZLIB always enabled on Windows contexts, so it will never default to the zlib shipped with FreeType and cause this conflict. It might be possible to use the FreeType zlib exclusively instead, but the config options for minizip are somewhat lacking in comparison.
Also note that I manually specify the x64 version of the library arbitrarily; at this point I'm still unsure if a 32-bit distribution is a valid Overgrowth target, but if that's the case this section might need a little more logic to ensure that the correct library version is linked.
After doing this, everything seems to just work™:

The only other hiccup I had was when loading some levels, I was seemingly getting another iterator loop error:
// engine.cpp : line 4116
for (auto obj : scenegraph->objects_) { // maybe regular for loop as well?
    if (!obj->parent) {
        obj->PreDrawCamera(predraw_time);
    }
}

I changed this to a regular i++ loop which seemed to fix the problem. Though, given how frequent and pernicious these iterator issues are, I feel it would be smart to discuss why/how these issues are happening and if it would be smart to either revert all these engine level loops to regular integer loops (as a quick fix), figure out some way to make the iterator stable when being modified (even possible?), or figure out some way to separate modification and iteration into 2 distinct steps (even feasable?). Should I create an issue/discussion about it?
Another question: I issued another pull request that fixed all the PVS warnings associated with Overgrowth in this issue. Should I bundle these changes into there and push the entire thing, or would you like them as separate PRs?

Separate PRs please.

how these issues are happening

if the list contents change while iterating it can break iterators. I imagine the iterations that call any script update functions will need to be swapped out or crashes may happen (whether in the base game, or in mods). there's functions to queue deleting items to help with problems like this, but they might not always be in use.
probably a different issue/pr tho.


Fix some inconsistency in gradient variable names.

According to the source code and the slides about double backprop., it seems a common practice to use gx and ggx to represent the gradients wrt x and gx.
However, some variables have contradictory names to this convention and new users may get confused about it. I hope they will be fixed by this PR.

The Travis failure seems unrelated to the PR.

jenkins, test this please.

Thank you for your review. I've made some changes according to your comments. Please confirm.

jenkins, test this please


Bump types-python-dateutil from <IP_ADDRESS> to <IP_ADDRESS> (#5635)

Pull request opened by the merge tool on behalf of #5635

Merged in cab5c81851e8470449ef2d00c5329a8c35c86409


Test harness compatibility improvements

[x] Python 3 support
[x] Fix port issue on Win

@Tahreeem Take a look and let me know what you think. I'll merge once you've tested this tomorrow.


AL Compiler 4.0.176004 cannot handle option field in Flowfield when the optionstring is 0,1,2,..

Describe the bug
Option fields with Integers as values cannot be handled in CalcFormula of Flowfield. Reservation Entry has such a field.
To Reproduce
Steps and to reproduce the behavior:
Extens sales line table with new field that calculates as:
AL Code to reproduce the issue
 field(50000; "Reserved Qty. on Inventory"; Decimal)
        {
            CalcFormula = sum ("Reservation Entry"."Quantity (Base)" where("Item No." = field("No."),
                                                                           "Source Type" = const(32),
                                                                           "Source Subtype" = const(0), //This line fails
                                                                           "Reservation Status" = const(Reservation),
                                                                           "Location Code" = field("Location Code"),
                                                                           "Variant Code" = field("Variant Code")));
            Caption = 'Reserved Qty. on Inventory';
            DecimalPlaces = 0 : 5;
            Description = 'Base';
            Editable = false;
            FieldClass = FlowField;
        }

Expected behavior
Yesterday the compiler showed error on this. Today with the same version it does not, However when i try to publish the App i get an error like:
Tab37-Ext50000.SalesLine.al(288,101): error AL0383: The option value '0' is not defined on field 'Source Subtype'.
Screenshots
If applicable, add screenshots to help explain your problem.
5. Versions:

AL Language: 4.0.176004 but runtime:3.0

Business Central: BC14 Cu4 (14.0.35916.0)

Hi @mfalk118, it seems that the newer version of the compiler fixes this issue, but that the issue still exists in the version of BC that you are using. When publishing an extension from VS Code, the AL code is compiled once in VS Code to create the package, and once in the server when publishing. This would explain why it fails when publishing with the same error you used to see.
Can you try reproducing this issue on the latest developer preview (version 15.x) and tell us if the issue still reproduces there?

It seems to be solved. You can close this


Add a button that enables/disables mocking from mimic

It should start in "enabled" mode, when in "disabled" mode it should not mock any requests.

Implemented in 2.0


cooking build 报错（新建的vue模板）希望尽快答复，急

cooking version

1.5.3
What is Expected?
希望解决这个问题
What is actually happening?
执行cooking build 后
<EMAIL_ADDRESS>- Loaded success: vue2
<EMAIL_ADDRESS>- Loaded success: lint
<EMAIL_ADDRESS>- Loaded success: sass
<EMAIL_ADDRESS>- Loaded success: autoprefixer
/usr/local/lib/node_modules/cooking-cli/node_modules/webpack/lib/Chunk.js:41
throw new Error("Chunk.entry was removed. Use hasRuntime()");
^
Error: Chunk.entry was removed. Use hasRuntime()
at Chunk.get entry [as entry] (/usr/local/lib/node_modules/cooking-cli/node_modules/webpack/lib/Chunk.js:41:9)
at /Users/liuchang/node_modules/extract-text-webpack-plugin/index.js:201:13
at Array.filter (native)
at Compilation. (/Users/liuchang/node_modules/extract-text-webpack-plugin/index.js:200:37)
at Compilation.applyPlugins0 (/usr/local/lib/node_modules/cooking-cli/node_modules/tapable/lib/Tapable.js:68:14)
at Compilation.seal (/usr/local/lib/node_modules/cooking-cli/node_modules/webpack/lib/Compilation.js:567:8)
at /usr/local/lib/node_modules/cooking-cli/node_modules/webpack/lib/Compiler.js:493:16
at /usr/local/lib/node_modules/cooking-cli/node_modules/tapable/lib/Tapable.js:225:11
at _addModuleChain (/usr/local/lib/node_modules/cooking-cli/node_modules/webpack/lib/Compilation.js:481:11)
at processModuleDependencies.err (/usr/local/lib/node_modules/cooking-cli/node_modules/webpack/lib/Compilation.js:452:13)
at _combinedTickCallback (internal/process/next_tick.js:67:7)
at process._tickCallback (internal/process/next_tick.js:98:9)`

/Users/liuchang/node_modules/extract-text-webpack-plugin
把你的 ~/node_modules 删掉