Custom popup using template

I have a question about angular leaflet directive customized popup using compile template. I am using ionic 1.2.4, angular leaflet directive 0.10.0 and leaflet 1.0.0rc-1.
In the controller, I wrote the following code.
var marker = {
            type: markerType,
            lat: myLatlng[0],
            lng: myLatlng[1],
            id: id,
            getMessageScope: function () { return $scope; },
            message: "howdy",
            compileMessage: true
        };

        $scope.markersArray.push(marker);

$scope.alert = function(){
            console.log("hahahahaha[");
        }

Although the link is presented in the popup, but the click event is never triggered, I think that the problem might come from the compile process. Any advice is appreciated. THX.

fiddle:  http://jsfiddle.net/caiczcz/m7g8Le0L/1/

maybe this is also a  compatibility problem for all the 3 libs.

It is compatibility with leaflet 1.0.0.

can anybody help?

$timeout(function(){
$compile(marker._popup._contentNode)(markerScope);
});


Requirements on the OAuth2 Protocol

The response type "code" and the grant types "authorization_code" and "refresh_token" are recommended by this specification.

Sammála að fylgja ráðleggingum Berlin-Group


[ Question ] Vanguard and possible changes

Hi, I haven't found this question anywhere, let alone the answer.
I know that the introduction of Vanguard greatly complicates the full use of the application and all add-ons, but are you able to determine the probability that you will be able to modify the current plugins to work the same or similarly after the applying Vanguard?
I must admit, your work is great and I would love for everything to work the same even after the anti-cheat was applied

How hard did you look? ;) #649 #615 #633 https://github.com/RCVolus/league-observer-tool/issues/132 https://github.com/RCVolus/league-observer-tool/issues/77
The "only" features impacted by Vanguard are ingame, where most things will break. It might be possible to memory read still, but it's fairly unclear and risky.


Move security details to parameters.yml.dist

As per http://symfony.com/doc/current/best_practices/configuration.html infrastructure parameters should go in the parameters.yml file rather than config.yml, this also enables different token lifetimes and key passphrases for development / production environments.

Nice catch !


L&S - Black Pawn art assets

Need the right files for the Black Pawn in the right places :-)
Based on an oreon miniion we need:

[ ] Animation in .md5anim format
[ ] Materials file in a .mat file format. I guess this is one of our simple file/asset (text) formats that references the texture png
[ ] Prefab that ties everything together
[x] Skeletal mesh in .md5mesh format which I guess is the model itself
[x] Texture png - this is the UV mapping thing that gives the model its skin

I've left placeholders with minimal content in https://github.com/MovingBlocks/Terasology/tree/develop/mods/lightAndShadow/assets as a simple example - works, too! If left as "oreon" in the prefab's Spawnable a placed "portal" will spawn the creature occasionally.
(glasz edit) model needs hands and weapons / tools

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/486391-l-s-black-pawn-art-assets?utm_campaign=plugin&utm_content=tracker%2F5279&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F5279&utm_medium=issues&utm_source=github).

Moved to https://github.com/Terasology/LightAndShadow/issues/13.


Only attempt to comment on PR if there is a PR

Very first attempt of a non-PR CI run failed because there was no PR to comment on: https://saml.buildvm.openshift.eng.bos.redhat.com:8888/job/art-tools/job/ocp-build-data-validator/job/master/1/display/redirect

If this works after merged I'll need to port it to all other repos that contain the same mistake.


Attach external site IDs to series table

Added new columns to the series table for tvdb_id, imdb_id, tmdb_id and trakt_show_id. These can be manually specified on a per-series basis through the config. This allows potentially more accurate searching through the discover plugin, since entries created by emit_series will have the equivalent fields populated if they are provided.
I don't know if it's worthwhile making any changes to the way the series filter parses returned entries, but hopefully this is useful as a start. I've tested it a bit (to make sure empty fields don't mess with searching for one), but let me know if there's anything I've missed.

This violates separation / coupling and makes it inconvenient adding new sites. More generic solution would be needed. One possibility would be adding columns like "site_id" and "site_name" .. but even that requires some more thinking ...

Totally agree, anything more complex is a bit beyond my abilities though. Open to any suggestions.

Hmm, i was discussing a similar idea with @gazpachoking .. We need a generic way to map a series to a site. Each site has it's own unique id and each site can name a series differently so what could we use for the unique id?

I'm still not sure best answer, but we can continue discussion if someone gets inspired.


pfTables displays n-1 items

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[x ] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x ] I have searched the existing issues and I am convinced that mine is new.

Describe the bug
At the UI http://opnsense/ui/firewall/alias_util/  for every table 1 Item is missing. I.g. if an Alias has 4 Members, only 3 are displayed but "show 1 to 4 of 4" is stated. If ther is only 1 entry for the alias, an empty List ist shown.
To Reproduce

Open aliases and edit one of them
Count the member entries of this alias.
Go to  pfTables http://opnsense/ui/firewall/alias_util
Count the entries.

This seems to be a problem only for this UI-table, other tables e.g. /ui/diagnostics/interface/routes count and display well.
Expected behavior
All entries should be shown. This is important for checking aliases of type "URL Tables (IPs)"
Environment
OPNsense 21.1.1-amd64
FreeBSD 12.1-RELEASE-p13-HBSD
OpenSSL 1.1.1i 8 Dec 2020
AMD GX-420MC SOC (4 cores)
UI-Language german

Already queued up for 21.1.2 https://github.com/opnsense/core/commit/8e90585b467


Cachet-monitor installation is not working on Linux system.

Hey, guys.
I am trying to install cachet-monitor on linux system, but it doesn't work.
It says: "cachet-monitor: command not found"
I've tried all the ways mentioned in the closed issues, but nothing helped me.

curl -L <download-link> > /usr/local/bin/cachet-monitor
cachet-monitor -c ....
This is not working. What do you mean download-link here?
I tried in this way.
curl -L github.com/CastawayLabs/cachet-monitor > /usr/local/bin/cachet-monitor
And run cachet-monitor. It says:

/usr/local/bin/cachet-monitor: line 5: syntax error near unexpected token `newline'
/usr/local/bin/cachet-monitor: line 5: `<!DOCTYPE html>'

go get -d github.com/castawaylabs/cachet-monitor
go install github.com/castawaylabs/cachet-monitor
Still not finding the cachet-monitor
Tried with cachet-monitor_linux_amd64 but it says like this:
invalid character '/' looking for beginning of object key string

panic: Cannot parse config!

goroutine 1 [running]:
panic(0x75c2e0, 0xc82000af50)
	/usr/local/Cellar/go/1.6/libexec/src/runtime/panic.go:464 +0x3e6
main.main()
	/Users/m/p/gospace/src/github.com/castawaylabs/cachet-monitor/cli/main.go:31 +0x16a

Can you guys please let me know the way to install on linux system?
@matejkramny can you please help me? :)
@moodhairboy can you check my post?

download link can be obtained from releases: https://github.com/CastawayLabs/cachet-monitor/releases
it can't be currently installed in the "go" way
is your config a valid json file?

@matejkramny Thanks for your response.

I ran these commands.
curl -L https://github.com/CastawayLabs/cachet-monitor/releases > /usr/local/bin/cachet-monitor
cachet-monitor
It says like this:
/usr/local/bin/cachet-monitor: line 5: syntax error near unexpected token newline' /usr/local/bin/cachet-monitor: line 5: '
This is my config file which is /etc/cachet-monitor.config.json.
{
"api_url": "http://cachet domain/api/v1",
"api_token": "api token",
"insecure_api": true,
"monitors": [{
"name": "CMP Url Monitor",
"url": "https://google.com",
"method": "get",
"strict_tls": true,
"interval": 10,
"timeout": 5,
"metric_id": 1,
"component_id": 1,
"threshold": 80,
"expected_status_code": 200
}],
"system_name": "system name",
"log_path": "/var/log/"
}

Sorry I meant, the releases url contains released binaries for your OS. You need to pick one and copy the URL.
If you're using Linux (64bit) then it would be: https://github.com/CastawayLabs/cachet-monitor/releases/download/v2.0/cachet-monitor_linux_amd64
Log path should be pointing to a file, might be the issue. Try /var/log/cachet_monitor.log

@matejkramny Thank you, Matej!
It works now. I really appreciated with your help.
You can close this issue. Thanks.


Disable cell output in scala kernel

In scala kernel, the output of the code in every cell is displayed. This becomes a huge problem when cell for example contains an assignment involving a list with millions of elements - the attempt to display that huge output cripples the notebook. Any way to disable outputs being printed out for every cell?

Hi  @gailmargolis76
have you tried to use  the OutputCell.HIDDEN ?
import scala.collection.mutable.ListBuffer
var list = new ListBuffer[Int]()
for (i <- 1 to 1000000){
    list += i
}
list
OutputCell.HIDDEN


CIF-745 [Product Teaser]

Description
Completes the story CIF-745 .
Related Issue
<https://jira.corp.adobe.com/browse/CIF-745
Motivation and Context
New Feature
How Has This Been Tested?
Create a new Page in Venia site with content-page as template. This template has setting for mapping Product teaser with parsys.
After new page has been created , you can either choose to use the existing parysys for drag drop of product Teaser from AEM.Venia category from sidebar, Or create a new layout container with lesser width (The size normally teasers are used in).
After it has been placed ,

You can either drag drop a product from side bar. You should have Commerce-CIF-Connector installed on author. Search for 'Shorts' in products type in assets sidebar. Currently there is no way to identify if the product is from magento or we.retail , so it would be good to check the url of the image in assets browser . You should drop magento products on the component Area. It will display the details of the Product.

You can use the dialog of the Component to configure the product. Choose the product from magento products in product picker.

You can also drag drop Magento product directly from sidebar and it will render as teaser .

Screenshots (if appropriate):

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[X ] I have signed the Adobe Open Source CLA.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ x] I have read the CONTRIBUTING document.
[x ] I have added tests to cover my changes and the overall coverage did not decrease.
[x ] All unit tests pass on CircleCi.
[x ] I ran all tests locally and they pass.

@AKumarSingh , could you update this branch from master to have a smaller diff.

Codecov Report

Merging #16 into master will decrease coverage by 7.95%.
The diff coverage is 5.35%.

@@             Coverage Diff              @@
##             master      #16      +/-   ##
============================================
- Coverage      48.9%   40.94%   -7.96%
- Complexity      104      111       +7
============================================
  Files            17       19       +2
  Lines           501      613     +112
  Branches         28       33       +5
============================================
+ Hits            245      251       +6
- Misses          244      345     +101
- Partials         12       17       +5

Impacted Files
Coverage Δ
Complexity Δ

...onents/internal/impl/ProductGraphqlServicImpl.java
0% <0%> (ø)
0 <0> (?)

...nal/models/v1/productteaser/ProductteaserImpl.java
17.14% <17.14%> (ø)
7 <7> (?)

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 a1d5e33...ab7e7ce. Read the comment docs.

Please review it , I have added the changes.


Update link checker

Add red warning/error color and change workflow from raising an exception to system exit.
Checklist

[x] By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and subject to the Developers Certificate of Origin.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Waiting on another review from @AMoo-Miki to verify that the linkchecker still works after a couple of fixes.

Superseded with https://github.com/opensearch-project/documentation-website/pull/3584.

Closing because everything will be implemented in #3584


Feature/1550 primary donor

@davidhabib this hotfix is ready for review, and for merge once build passes.

@njjc reviewed and found one label that needs to change.  and the build failed :-(


Feature extension

Use user input joi like joi-extension
Add extension function for support self extension of openapi for full support joi or other reason

exclusiveMininum and maximum should have been in the other merged PR as adding additional support. Not this feature request.
As far as extensions go, I think we could accomplish the same thing with refineType and changing the refineType function to accept the current value (which can then be introspected).

Closing in favor of #55 and due to being outdated.


MX-100 - Removes SearchLink from Fair

This is the Emission side of MX-100
Paired with @brainbicycle on this as a first-issue
MX-100

:rocket: PR was released in v1.19.17 :rocket:


User profile admin override

The only way to override a value on user's profile right now is to directly edit the json file. This functionality should be exposed to all admins through commands.

removed user profiles in https://github.com/scp-cs/Thorn/commit/eeee78067264f1a96c4ed0a827ca06c1a90a5d0c


Add curved beams in vtk

Add the option to visualise beams with more than a linear interpolation. Concrete, Hermite shape functions are used to visualise a "smooth" beam. In general this does NOT match the exact interpolation used in FE solvers for higher oder beam elements.

@isteinbrecher Would it be possible to use the exact FE interpolation also for visualization?

Just out of curiosity and to better understand the entire beam framework in 4C and meshpy. As far as I understand you now added the option to visualize the beam geometry with more than one segment within the .vtu output.

This now basically resembles the procedure for the visualization within 4C?
This entire procedure is done because ParaView does not support Hermitian shape functions?

Thanks in advance!

@mayrmt Possible yes, but in my opinion not feasible, as one would end up implementing the beam formulation from the solver in MeshPy just to get a better visualisation.
@davidrudlstorfer This pull request simply introduces the option to get a better visual approximation of the geometry in MeshPy. Hermite shape functions are used for convenience, not because this now matches the interpolation in 4C.
Take for example a simple half circle modelled with 2 beam elements. The vtk visualisation in MeshPy used to always look like this (now with beam_centerline_visualization_segments=1)

Now it can look like this (with beam_centerline_visualization_segments=5)

In the near future, I envision to set the default value of beam_centerline_visualization_segments to 5.
With newer VTK versions ParaView supports Hermite interpolations, but this comes with a lot of other drawbacks. From my experience the "piecewise poly line" visualisation is the best solution to display 1D beam elements in ParaView.


lv_conf_checker syntax changes

A few syntax changes, the only functional change is that preprocessor tokens are matched with regex.

Thank you!

I've just noticed one thing: f'...' syntax is valid only since Python3.6. Could you replace it with something more "common"?


chore: update dependencies

CHANGES:

Updated kiwi to support analyzer 4.0.0

Because kiwi_generator >=4.0.2 depends on analyzer ^3.2.0 and freezed 2.1.1 depends on analyzer ^5.0.0, kiwi_generator >=4.0.2 is incompatible with freezed 2.1.1.

I'm closing the PR as it became irrelevant with the newest kiwi updates.


[enh] picture in picture for 3D view

as alternative view for full screen mode
in 3D, on drag on mesh/slice for oblique slice

introduced as of v2.9.0


Processing browse request throws Error: illegal tag: field no 3 wire type 7

browse_reqeust.tar.gz
Hi, I've been trying to implement a surge alternative, when trying to process browse request with nodejs, I found that this browse request will throw Error: illegal tag: field no 3 wire type 7.
It seems that the protobuf types are mismatched, potentially causing the first ad when opening a video not to be blocked.
Here is the code I use to process the request:
const fs = require("fs");
var store = {};
var e = null;
var $persistentStore = {
  read: (key) => {
    return store[key];
  },
  write: (value, key) => {
    store[key] = value;
    return true;
  },
};
const res = fs.readFileSync(
  "./tp-dump-request-https___youtubei.googleapis.com_youtubei_v1_browse"
);
const req = fs.readFileSync(
  "./tp-dump-request-https___youtubei.googleapis.com_youtubei_v1_browse"
);
var $request = {
  url: "https://youtubei.googleapis.com/youtubei/v1/browse?key=AIzaSyB-63vPrdThhKuerbB2N_l7Kwwcxj6yUAc&retry=1",
  body: new Uint8Array(req),
};
var $response = {
  url: "https://youtubei.googleapis.com/youtubei/v1/browse?key=AIzaSyB-63vPrdThhKuerbB2N_l7Kwwcxj6yUAc&retry=1",
  body: new Uint8Array(res),
};
var v = null;
var $done = (obj) => {
  console.log("=======", obj);
  v = obj;
};
console.log("Before eval");
eval(fs.readFileSync("./youtube.request.beta.js").toString());
console.log("After eval");
console.log("Result: ", v);

Can you help me with why the video's first ad is still showing up?

This error is generally a problem with deserializing the protobuf.
It could be because the data is not a protobuf, or the proto file was written incorrectly

Thx! I guess the problem is that I assumed that whatever URL that matches the rule is protobuf, but that is not true.


Fix my code a little

All what I do in Pingendo

All what I do in Pingendo please fix errors in Visual Studio Code


Configuring enabling / disabling custom visuals and uncertified visuals via Microsoft Intune

Hi,
This document explains how to disable custom, and uncertified visuals via AD Group Policy, but we use MS Intune in our organisation (as per MS recommendation).
Where can we find the instructions on how to carry out the above activity in MS Intune?
Thanks
Kris

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 67bf91c4-cbf2-0b4c-2532-4ade0d56afee
Version Independent ID: 687beece-c5e9-070f-9794-fc6569bb09b0
Content: Organizational visuals - Power BI
Content Source: powerbi-docs/admin/organizational-visuals.md
Service: powerbi
Sub-service: powerbi-admin
GitHub Login: @mberdugo
Microsoft Alias: monaberdugo

Thanks for your comment, @KrisMedici. This issue has been assigned to the doc author for review.

Thanks for your question, @KrisMedici. I'll look into this and get back to you.

Sorry for the delayed response, @KrisMedici. As far as I can tell, this question relates to group policies.
Here are a couple of links about setting group policies in Intune. I'll add them to the doc.
Use Windows 10/11 templates to configure group policy settings in Microsoft Intune
Tutorial: Use the cloud to configure group policy on Windows 10/11 devices with ADMX templates and Microsoft Intune
Hope this helps.


kicker doesn't detect certain imposter bots

this also happens sometimes with imposters

I have considered checking if new players have copied the name of another player on the server, however it isn't uncommon that friends or groups of players might join with the same name for a bit of fun (e.g. "Engineer Gaming" etc). So in order to avoid false-positives I do not intend to check for duplicate names. Instead I recommend recording these players' steamIDs through the program manually if they are not automatically detected.

it didn't even put them on the list though when they copied my name

What do you mean? They wouldn't show up in the player list or it didn't record them as bots into the recorded_bots.txt list?
It is an intended feature that another player with the same name as you is not recorded as a bot.

the ones with the <player_name>? name didn't show up at all in the player list.

no matter what

Interesting, I will look into this and see if I can find the problem.

also, ones without the ? don't get kicked at all. period.

I cannot seem to recreate any issues with accounts connecting with duplicate names, for the most part those names are automatically prefixed with a number to make them stand out, and any duplicate named accounts that don't get matched by the regex are not intended to be identified as bots and kicked.
If you encounter an issue with this and are able to screenshot an example I may be able to help some more,

there are bots that will steal your name without having a number before it.

i'll test this out in the new release when it comes out

so far, it has been attempting to kick imposter bots. i'll update if anything bad still happens.

The bot kicker has trouble identifying these bots for some reason. They don't even show up in the player list.

Also, why does it truncate my name half-way?

this also happens sometimes with imposters

Also, why does it truncate my name half-way?

I've made it truncate the names at a certain character limit so it doesn't overlap with the stuff on the right with default window size, maybe I will make it adjust with the window size.

this also happens sometimes with imposters

I'll try look into this in a little bit. I personally haven't encountered too many bots like this on the servers I play on so I may have to ask you for a little more, apologies. If you see these bots again could you please grab the output of the status command as well?

this also happens sometimes with imposters

I'll try look into this in a little bit. I personally haven't encountered too many bots like this on the servers I play on so I may have to ask you for a little more, apologies. If you see these bots again could you please grab the output of the status command as well?

It looks like that one fucks up the format of the player list

here's another instance of these question mark bots
it could be a normal imposter bot, though. i'm not sure

alright, so anyone who has your name isn't added to the player list. don't check if someone is you by name

That is very unusual, players are all handled by their SteamID in the program so I'm not sure why their name would cause a problem like this. I'll try and find the problem when I have time.
Sorry to keep asking for things again, but if you come across them again could you get the output of both status and tf_lobby_debug as well?

Well after a long time I fixed the issues for accounts that have weird names or change them during gameplay. I did also add some name-steal detection but maybe too late, hopefully it isn't needed with Valve's patches.


SIM ready call gsmi_get_sim_info(0) cause system deadlock

    /*
     * In case SIM is ready,
     * start with basic info about SIM
     */
    if (gsm.m.sim.state == GSM_SIM_STATE_READY) {
        gsmi_get_sim_info(0);
    }

#define GSM_CFG_INPUT_USE_PROCESS 1
now is in gsm_input_process and gsm_core_lock,  gsmi_get_sim_info(0) call gsmi_send_msg_to_producer_mbox will be failed

how to deal with GSM_CMD_SIM_PROCESS_BASIC_CMDS command?

gsmr_t gsmi_get_sim_info(const uint32_t blocking) put in gsm_sim.c (gsm_sim_get_info(const uint32_t blocking) will be better

Did you try it or is it from code review only?

I want to port this library to linux platform and use pthread_mutex_lock.
Calling "configure_sim_card()", it can't return. So I traced the code.

Mutex must support recursive lock. Then it will work well.

OK. I will double check my code again. Thank you!

Set the mutex attribute PTHREAD_MUTEX_RECURSIVE,  It work!


[Q] Consistency guarantees for reads in an uncommitted Spanner transaction

Hello,
If I perform some reads using a transaction provided to the mutator given to spanner::Client::Commit(), will the results always reflect the state of the database from some timestamp, even if the transaction later fails to commit? For example,

Say that I do a lookup by key, and in the db there will always be at most one row for that key (say it's a primary key). Will the Read performed in an uncommitted transaction always see at most one row?

Say I have two columns in a table, and the application logic guarantees that for every existing row, exactly one of these columns will be NULL. Is it possible for an uncommitted transaction to see both of them NULL, or neither?

Thank you!

If I perform some reads using a transaction provided to the mutator given to spanner::Client::Commit(), will the results always reflect the state of the database from some timestamp

Yes.  http://cloud/spanner/docs/transactions says:
A transaction in Cloud Spanner is a set of reads and writes that execute atomically at a single logical point in time across columns, rows, and tables in a database.
And that implies that the answers to your other questions are (1) yes, and (2) no.
Read further down that page, particularly to the Isolation section for more information.

If I perform some reads using a transaction provided to the mutator given to spanner::Client::Commit(), will the results always reflect the state of the database from some timestamp

Yes.  http://cloud/spanner/docs/transactions says:
A transaction in Cloud Spanner is a set of reads and writes that execute atomically at a single logical point in time across columns, rows, and tables in a database.
And that implies that the answers to your other questions are (1) yes, and (2) no.
Read further down that page, particularly to the Isolation section for more information.

Thank you very much.

Thank you very much.


Create Application Diagram

http://www.gliffy.com/go/publish/image/10979575/L.png

Updated process flow based on 8/22 project night https://www.gliffy.com/go/publish/image/11043599/L.png


Save Modified Config File

Hi,
I came over from the original spdlog repo after I found this awesome extension for spdlog. After the removal of the dependencies its really much leaner and I am planning to use this in our production software. I extended spdlog myself before in a similar way, making it possible to load only log levels from a file. Being able to fully setup the loggers and sinks via config file is a very good improvement. The only thing my implementation provided which is missing now is the option to permanently change the config during runtime. Do you think a option like this could be implemented here also?
I could imagine a solution wich looks like this:

The default_config.toml is never touched
If the user modifies the log level during runtime and wants this change to persist he can save this.
A new custom_config.toml is created and saved to disc.
When the program starts and tries to load the default_config.toml it looks for a custom_config.toml and prefers this over the default_config.toml if found.
The user can also reset to default_config.toml at any time and the custom_config.toml is deleted.
A restart of the program would now load the default_config.toml since it cant find any other.

How do you think? Could you imagine such a feature?
Cheers!

Hi, it is possible if there are API calls to perform all the getter methods (e.g. get all loggers, get logger name/format, etc.), but I am not currently sure if there are sufficient getter methods to achieve the above yet, since the current extension mostly uses the setter methods of spdlog.
I will check through the spdlog API, evaluate and let you know again.

I am afraid I would have to decline your proposed suggestion; spdlog API has an extensive range of setter public methods, but very few getter methods (seems like only the name and level of a known logger can be retrieved). It would be impossible to properly implement your idea of persisting the registry of loggers (plus sinks and formatters) without the necessary getter methods, and at the same time I do not have control over the public getter methods required.
My apologies and I hope you can accept the explanation.

Yeah I encountered pretty much the same issue when I was implementing it by myself.
Since I only dealt with the log levels and not with the sinks and formatters I implemented a getter for all loggers like this std::vector<std::shared_ptr<spdlog::logger>> getAllLoggers();
I think something similar could be added to spdlog? Maybe we could figure out which getters are needed and add them to spdlog by making a PR?

It could be difficult, basically all the fields that you see in the static file config example, which most of them pertain to specific sinks, and also the starting point getAllLoggers that you have mentioned (as well as getSinks and getFormatters per logger/sink), which pretty much means all setters must now have getters methods. From spdlog's perspective, this would probably open up too much details for typical usage.
I am curious as to why you might need such a feature haha? Personally I haven't seen any log library doing the reverse (i.e. runtime logger fields back into a serialized config state), and haven't encountered issues with just having to set the config values before running the program.

We have many distributed systems. Customers can request support and in such case its often necessary to increase log levels e.g.. Changing them during runtime is fine wich spdlog provides. But the customers are frequently restarting their devices, which would cause the default config to be loaded and the debugging log level is gone. So there needs to be a way to permanently save the log level. For this use case its all about the levels only. No need to change sinks or formatters.

I see and thanks for sharing your use case. It is possible to implement the above with some form of basic override config file (similar to docker-compose override YML files?), and it does seem possible to have the override file following the original config file TOML syntax, just that in reality the override file is only able to have the logger and its overridden level.
For example based on my example original TOML config with root logger having trace level, one could override the level with the following log_conf_linux.override.toml:
[[logger]]
name = "root"
level = "info"

The above would make it possible to be forward compatible if in the future, when more getter methods become available (though unlikely).
There would also be a need to have the user specifying whether to allow override (override file will have a default filename based on the given original TOML file). As to when to perform the override persistence, I would suggest doing through an additional spdlog_setup method to take in the logger shared pointer, and the method will attempt to serialize whatever possible info based on the current getter methods available.
How does the above sound?

That sounds like a very good solution for my given problem since I really only require the levels to be overridden. What do you think needs to be done and could I assist you in some way?

No worries, I will try out a bit myself first since it shouldn't be too particularly difficult, then maybe you could provide some feedback for me 😃

@p0fi Sorry for the delay, just delivered #14 and I believe it should be sufficient to resolve your issue.
There are 3 additional functions in the v0.3.0-alpha.0 that you can use:
// override_toml_path can be your anticipated override file path to use
// the file can be missing at the start, which then only use base_toml_path
// returns true when override file is used (i.e. not missing / error opening file)
auto from_file_and_override(
    const std::string &base_toml_path, const std::string &override_toml_path)
    -> bool;

// only saves name + level, overwrite to always be false
// this allows the new logger entry to be saved into the new override file
// and subsequent saves should only change the level value
// from logger of the matching name
void save_logger_to_file(
    const std::shared_ptr<spdlog::logger> &logger,
    const std::string &toml_path,
    const bool overwrite = false);

// removes the TOML logger entry just for the matching name
// true if such entry exists and is deleted, otherwise false
auto delete_logger_in_file(
    const std::string &logger_name, const std::string &toml_path) -> bool;

Hopefully should be enough for your use case. Let me know if there are issues (hopefully not as new unit tests were added) or other comments. :slightly_smiling_face:

Hey,
thanks a lot! I tried this a little bit and it works nice when all is done in one source file (log setup and handling of overriding). I do want to handle the overrides based on user input, which is handled in a separate source file. When I now do in this source file #include <spdlog_setup/conf.h> I cant get it compiled anymore. I do get linker errors about duplicate symbols. I checked this a little and found that some non inline functions in the header files might be the reason. See this answer on stackoverflow. Can you confirm such problems?

There are indeed missing inline for the setup_error methods, thanks for pointing out. I have patched them and can you help to check if my latest merged PR #15 resolves the issue?
You can just check out tag v0.3.0-alpha.1 or the latest commit from master.

Thanks for the fast patch! It works now!
I'll think I will implement the new possibilities next week and could give you feedback after.
Thanks a lot again for implementing this feature in the first place! 👍


Security: Improper handling of U2F counters.

The reference applications incorrectly handle a rolled back counter -- needs to disable the login on valid signature with a rolled back counter to prevent security failures. Current model allows for counter iteration, defeating the security of the counter.

Any response at all?

As far as we could tell from the U2F specs, there is no way to do anything useful with the counter as it is it can wrap and it is underspecified how devices uses the counter.  Do you have any suggestions otherwise?  Also, as far as we could tell, there is no real security problem caused by this anyway.

facepalm No real security problem? This allows for counter iteration and dual-use of a cloned token. This is not only a security problem, but a critical one. There are a number of strategies that must be put in place for counter tracking -- the most important of which is tracking for a simple signed rollback @ < countermax. However that's not a real solution either as a token cloner would simply use cloned values of countermax-1, countermax, 1 and then the cloned counter value again to reset state. The counter is a key part of the security model in the U2F spec and is definitely not optional. Devices must be watched for rollover (likely involving a lockout and re-enrollment) and for the more obvious simple rollback.

Please explain how we could do better.  As far as we can tell, there is no way to check the U2F counter in any generically useful way.  I believe our library allows your application to retrieve the counter value, so your application can perform counter-related checks.  However, as a library, I have not been able to see any useful checks that are possible.
To give you some background, let's cite all text in the specification related to the counter.
Quoting "FIDO U2F Implementation Considerations" section 2.6: "A U2F token must increase a counter each time it performs an authentication operation. This counter may be 'global' (i.e., the same counter is incremented regardless of the application parameter in Authentication Request message), or per-application (i.e., one counter for each value of application parameter in the Authentication Request message).   U2F token counters should start at 0, and wrap around to 0 when they have reached their maximum value."
Quoting "FIDO U2F Raw Message Formats" section 5.4: "A counter [4 bytes]. This is the big-endian representation of a counter value that the U2F token increments every time it performs an authentication operation. (See Implementation Considerations [U2FImplCons] for more detail.)"
Quoting "Universal 2nd Factor (U2F) Overview" section 8.1: "The U2F device protocol incorporates a usage counter to allow the origin to detect problems in some circumstances. The U2F device remembers a count of the number of signature operations it has performed -- either per key pair (if it has sufficient memory) or globally (if it has a memory constraint, this leaks some privacy across keys) or even something in between (e.g., buckets of keys sharing a counter, with a bit less privacy leakage). The U2F device sends the actual counter value back to the browser which relays it to the origin after every signing operation. The U2F device also concatenates the counter value on to the hash of the client data before signing so that the origin can strongly verify that the counter value was not tampered with (by the browser). The server can compare the counter value that the U2F device sent it and compare it against the counter value it saw in earlier interactions with the same U2F device. If the counter value has moved backward, it signals that there is more than one U2F device with the same key pair for the origin (i.e., a clone of the U2F device has been created at some point)."
Let's say you have recorded a last known counter value of, say, 42, and receive 43 or 41 as a current counter there is no useful distinction to be made as far as I can tell.  If you received 43, things may be fine, but the counter may also have wrapped (due to large number of uses against some other site, assuming a global counter) and there is a cloned device out there.  If you receive 41, things look fishy, but the counter may just have wrapped and there is no cloned device.  As far as I can tell, the only useful way to check the counter is for the APPLICATION to perform two U2F Authenticate operations after each other, and compare the counter values.  This minimize the chances that a counter wrap occured.  In theory, the user might perform ~2^32 U2F Authenticate operations against some other site between the two attempts, but if the time passed between the two attempts is small, this is unlikely.  I argue this is hard to know inside the library, though, making it hard to do anything useful inside the library.
I would prefer to resolve this issue by changing the specs to say that U2F counter rollover MUST NOT be permitted by devices.
Thoughts?

Yes, the counter could wrap, and that's acknowledged in the spec, but that's not something that should be considered normal expected use of the token. It definitely shouldn't invalidate any use of the counter to mitigate device cloning.
If a counter wraps, and starts sending wrong numbers, that token should probably be considered invalidated against all the places it's currently authorized with. That's certainly annoying for a token holder, and there's no guarantee on how many bytes the counter has available to it, but 2^32 U2F authentication operations is over 4 billion operations.
Even 2^16 operations is 65536, which would take 3 login attempts a day, every single day, for 60 years, to wrap.
And that's only for the worst case: a token which uses a single global counter for all logins. The spec notes that using such a global counter will leak privacy across websites (it becomes much easier for multiple service providers to make a good guess at whose token is which in both databases), and that tokens with larger memory requirements may/should use separate counters -- either for individual sites, or buckets of sites.
In fact, a counter wrap is perhaps only viable when an attacker has taken control of someone's token and put it through mechanized counting attempts in an effort to wrap the counter. In which case: please consider my token invalidated! :smiley:
That's all to say that counter wrapping is a highly exceptional scenario. So if when it does happen, someone's token gets effectively de-authorized from all their existing sites and needs to be re-authorized -- that's probably okay. Every U2F-implementing site is going to have a way of dealing with lost or stolen tokens, and that can apply in situations where a counter has gone awry.

In your example, you must catch 41, after 42 as a cloned-token. A rollover is, as you point out an exceptional and rare event that should never happen in legitimate usage, and as you point out, really probably shouldn't even be allowed by the spec. Part of the problem with the U2F spec is the use of wrapped-keys and global counters. Really, this should be a per-realm keypair and a per-realm counter in an ideal world.
Regardless, the solution ( within the spec allowance of global counters and wrapped keys ) -- I would add to the lib a data access layer (either as an interface to be implemented or just as user-model object) indicating that there are certain user metadata fields that must be stored and monitored for secure operations. At a minimum those fields should include the counter details, number of authentications, and track key rollovers, authentication events and failures, etc.
It may take some Bayesian math to decide when to throw an audit or lockout event, however, I would suggest if the counter moves more than > 256 or so points between authentication events or exceeds a rate of say 128 auth's per 24 hours, it needs to lock the token out and throw a security exception of some sort. If the counter rolls back outside the rate limit, you know it has been hacked and must lock it out and alert an administrative user.
Ignoring the counters as is currently implemented (and as is being picked up by relying parties) however, leaves a massive everyday security hole, where the utility of the counter is entirely negated, and detection of token cloning just wont happen in practice.
TL;DR: add a Security Exception framework, User Metadata tracking model and some rate limiting algorithms and check counter values for rollback. Update docs to include a checklist that there's a mechanism for notifying an admin if a security exception is thrown.

The code related to the counter check in the library is here:
https://github.com/Yubico/php-u2flib-server/blob/master/src/u2flib_server/U2F.php#L283
So the counters aren't ignored, as I mistakenly assumed.  However, applications using this library needs to pay attention to this issue, which may turn this into a documentation feature request issue.  If someone would contribute a security exception framework, that would be awesome, but pending that, simply documenting that if you get a 'counter-too-low' exception, you should invalidated the credential for that user and alert the admin of a cloned device.  Anything missing with that approach?

None of the implementations of this lib pick up that exception as anything but an auth failure. Also, that code was added after this bug was opened. If left as is, I'd wager on this being ignored in the ecosystem and cloned tokens being an effective hack. Better to fix it now than try to redeploy the tech in the face of cloning.

So the counters aren't ignored, as I mistakenly assumed. However, applications using this library needs to pay attention to this issue, which may turn this into a documentation feature request issue. If someone would contribute a security exception framework, that would be awesome, but pending that, simply documenting that if you get a 'counter-too-low' exception, you should invalidated the credential for that user and alert the admin of a cloned device. Anything missing with that approach?

Totally. The library should (as I guess it does?) consider a too-low counter an invalid authentication. Implementors should be aware that that's one of several possible reasons an authentication could fail.
In my own implementation work, I don't know if I'd even try to communicate to the users the threat of cloning -- I might just say: "Unfortunately, your device has gotten out of sync with our application and needs to be reauthorized." and then take them into the lost/stolen token workflow.

@konklone A simple auth failure is useless here as the attacker will just move the counter up by one until he hits the next valid counter. Then when the real user logs in next time, they'll get one auth failure followed by an auth success --- and unless the implementer is tracking counter-too-low exceptions to the db (which isnt in this pattern), no one will really be the wiser.

Agreed -- I believe that as soon as you get ERR_COUNTER_TOO_LOW applications must invalidate the credential rather than treating it as an authentication error.

Also note that typically the device that would trigger this error would be the original device, not the cloned one, as an attacker who is able to clone a U2F device is surely capable of incrementing the counter value by a sufficient amount to make it higher than the counter stored in the database for that user.  So when this incident is noticed by the server, an attack has likely already occured earlier on.  What to do in a situation like that is not simple, and probably depends on what you are implementing, so it is an application concern.

Well, yes/no. If the attacker is smart he'll start at the cloned value and iterate up if long-term access is the goal. In such cases, it will be the cloned token generating a number of auth failures until the right counter is hit. Then the real one hits one bad login, tries again (cuz users always do) and it works -- so no alert gets raised. So no, not really in the realm of the app, but rather in the realm of the 2fa scheme.

Sure, if the attacker wants long-term access at the cost of being possible to detect -- I assumed attackers would prefer to stay undetectable.
So can you suggest anything the library can do to make applications/integrators pay attention to this issue?  Or should we punt this to improved documentation of the library?  It seems simple: ERR_COUNTER_TOO_LOW => invalidate credential.

Are there any other error conditions which suggest the application should invalidate the credential?

The attack scenario for token cloning is the classical temporary access to longterm access... the ol 'at a border', industrial espionage ala apt, etc... its rarely just to gain access as you can pull that off by simple theft or other local system attacks.  What we're talking about here is defeating some sort of supply-chain interdiction, apt, etc.. Thats why these counter exist, to prevent two tokens from co-existing.
I think the library has to re-evaluate the in/out here. What is it trying to provide? If its an implementation for U2F, then that really has to include metadata tracking and security event notification and token lockout, beyond that of a 'please watch for err_too_low' doccomment, because we all know how PHP developers stop coding at 'it works'.

@konklone several. Multiple invalid authentications would stand out, valid auths with counter gaps too large for the time (eg noticing the token has had 1000's of auths in 24 hours or similar) which would indicate some sort of adaptive brute force against the token. (Remembering that the brute force doesnt have to occur against the server application, but rather can target the token in an offline way)

Hmm. So I'm implementing this in my own site, this afternoon, and I can see why invalidation has to be an application level concern. For any application where keys are an extra level of security, but not required -- if you just invalidate someone's token, it effectively lowers their security and lets an attacker remove their second factor. It's got to descend from a site's policy on how tokens fit into their workflow.

That wouldnt be the lockout pattern that I'd suggest -- rather the token should still be associated with the user but not allow login. Answer's not removing the token from the account. Basically, the metadata creates an auth check that can no longer pass....

If you leave it up to the implementer, and outside the lib, you're basically trying to require everyone using U2F to be an expert in this stuff, to understand things like counters and their purposes. That doesn't make sense to me. Better that the lib provide clear input/output patterns that encapsulate the full responsibility of the spec/token.

"the token should still be associated with the user but not allow login"
The outcome is the same, legitimate user can't auth with the physical token, DDoS ensues. Yes you should probably have a spare but the reality for those of us not doing U2F dev work is end users won't.
As far as I can see U2F tokens have no protection in software/api against being cloned as hardware OOB [and they probably shouldn't -] it's for people to maintain their personal physical security of their tokens, and at the end of the day that's why we're talking about second factor as opposed to single factor maintained by a token.

No, no ddos vector is created, as you have to be able to get to valid signature. Only way to force a ddos would be to be able to valid-sign the counter value (and for it to be wrong)... in which case, you definitely want that token locked out and the account locked.

You were talking about a cloned token were you not? If you're managing to clone a token then you can create a valid signature, did I read it wrong?

If the token is cloned, you want the account locked; you are not worried about a denial-of-service attack in this scenario; the signature prevents denial-of-service by a user that is, lets say, unauthenticated. The counter prevents credential cloning, but if it is detected (by a bad counter value), you don't want to say 'but that would lock out the legit user'... you definitely want the account locked as the key has been lost.

In short; the code needs to be patched to track the counter values, to do more than just reject a login if it detects these type of valid-signature with bad counter errors. For the counter mechanism to work, the account has to be locked out on rollback/rollover. I'm starting a project soon which will use this library, so I may get to hacking it in soon enough, but if yubico+crew could get to it faster it would save me the time.

You want to know, you don't want to be prevented from getting into systems - it's multi-factor. The second factor isn't the be all/end all of your account security.

In the typical pattern the U2F challenge occurs after a password login has succeeded @streaky ... you definitely want the account locked out if the counter falls back. 100% of the time. No legitimate use case for a counter rollback.

Actually no you're right.

@jas4711 sorry if this has already been addressed and I missed it but is there a ERR_COUNTER_TOO_HIGH?
If not then all you would have to do to clone a token is increment the counter to a value that is likely higher than the user's current counter. So as mentioned above "Even 2^16 operations is 65536, which would take 3 login attempts a day, every single day, for 60 years, to wrap.", just set the counter to 65535 and then cloned token would successfully authenticate.

@onlykey this issue was never really resolved, a counter too low exception was added but it doesnt address any of the counter-tracking issues. There needs to be tracking if a counter skips ahead too far, if it resets/wraps, etc... none of thats really handled today so yes, a cloned token would work very reliably in practice.

@StormTide Ok thanks for the info, it sounds like there may not be an easy way to prevent device cloning. If you set a low/high counter threshold of say within 100 there is a chance a user could lock themselves out if they don't log into an app for awhile. And even this would not prevent cloning/backup of a device using a method like Trezor uses.

Except for physical defences of the device of course. You can't just copy the keys off it - so it would take some physical effort though not impossible at the same time. It never purported to be impenetrable - it's a second factor after all. You can do things server side to track things like the counter though if you really care, it's just not in the default stack.

Actually it is a required part of the spec, this lib just isnt conforming.

@onlykey I'd think the threshold you'd be looking for would be like 2x the highest counter increment you have ever seen from a legit user. For most workloads a sane value would be like 50 + (24 * days since last login). If it moves more than that, lock out the account and go through a CSR process for recovery. What you're trying to detect are large moves in the counter value that wouldn't happen under normal user login situations. Eg 65535...  As for the Trezor recovery reset to 0, thats precisely the kind of reset you're trying to trap with this logic.
A fake/cloned token would generally know its own counter value at time of cloning. An attacker will then want to jump forward until the counter works (which would trigger err too low if they're not the exact next login)... or jump ahead to a safe/clean value (and maybe counter advances too fast for a legit user)... the goal here is to either catch the too low and lockout, catch the too high and lockout or to catch the legit user and lockout on their next login preventing long term use of a cloned credential. In any event, these need be more than login failures but rather enable some sort of account lockout procedure as they occur after authentication and do indicate a serious fault condition.

@StormTide The 2x the highest counter approach sounds good but taking a threat modeling perspective, If I am an attacker that has found a vulnerability that allows reading values from a token and I want to clone it and I have access to the current counter, attestation key, and handle key then I can create an exact copy of this token that would work to authenticate. If I can read all values from a token except for the counter (very unlikely I think) then I would have to guess a number within the 50 + (24 * days since last login) range.  I understand its part of the spec but looking at this it sounds like maybe this should be reviewed to see if this really offers value or just creates situation where legitimate user could be locked out.
The Trezor approach from how I understand it uses the current unix epoch timestamp as the counter so when you backup/restore a token the counter is always ahead (unless you use a token more than once a second) and still would always be within 2x the highest counter seen. So this would still work.

@onlykey what would happen then is that the next time the real user logs in they would get an err counter too low and lock out. The goal of the counter here is to detect long term access and prevent token duplication. (Think a high-security corporate employee going through a hostile border, etc)
The spec doesn't allow for an epoch as the counter, it needs to actually be incremented per user interaction. Its actually supposed to be per-site, but lots of the tokens share a common counter between sites.

This is a really intresting discussion and I also want to add a few things.
@StormTide
"Part of the problem with the U2F spec is the use of wrapped-keys and global counters. Really, this should be a per-realm keypair and a per-realm counter in an ideal world."
generally this would be nice, but I have had the experience of one of my U2F keys (which even was my favorite U2F key) basically doesnt register any new sites with an insufficient resources, and considering they seem to have seperate counters it probably failed because I dragged too many registrations on it (which can obviously happen when you webdev which U2F) which obviously is VERY annoying.
one thing we could talk would be for example having a bunch of pre-created counters and based on for example the hash of the appid or the keyhandle or whatever the key selects which of the counters to use.
with wrapping keys (no matter whether we just encrypt them into the key handle or play (CS)PRNG shenanigans, as long as the method makes sense and is secure and does not allow easy correlation of the keyhandles to the U2F sticks (the whole point of this system in the first place), because while I have no Idea of the prices, I doubt that tamper-proof and/or -evident storage especially if it's supposed to be writable like with the counters is cheap,
There's probably a reason why with FIDO2 the Yubis only allow 25 resident keys while solo goes with 50, and while for many that may be enough, with 47 2FA credentials in my Authy, AND the fact that you cannot erase single Fido2 keys but have to reset the entire key (which also knocks out all U2F keys along the way)I am WAY past that limit especially if we include the fact that services which currently rely on SMS for 2FA may someday adopt U2F/Fido2 and the fact my Yubis probably have a few dozen dead registrations from webdev, I am WAY over those limits and it obviously is NOT feasible to split the websites among the keys as that would end in utter chaos.
also I think this whole Key wrapping business (again, considering both styles) is basically just similar to a password manager, except that the service gets to store the user-crypted password and that the wrapping does not rely on a potentially weak user-password, but a device secret inside a secure element which, generally, shouldnt be able to be directly accessed without literally destroying the key (thereby leaving evidence so the customer can for example knock out the credential or inform the site owners of the breach)
@konklone
Regarding the whole rollover issue, with some more recent keys it's FAR more plausible than ever before, because they try to work around the privacy issue of global counters with non-uniform increments which in the worst case be in the hundreds easily, which then again makes rollover testing a real pain as you cannot properly say how much you can expect any given U2F key to increase the counter over any given time period, also 2^32-1 fell quite a few times because of the counter.
I think we can knock off yet another bit from this as some languages and/or applications can't handle unsigned 32 bit numbers but treating them as signed instead and I doubt that many will actually try and write a "unsigned-style-check" which goes and compares the number in way to treat negative numbers as larger than any positive number. currently though I can say that it still should be rare as long as the keymakers don't overdo the increments but saying 2^16 is enough is definitely not right in those circumstances, although granted, your post was made an entire year before I even got my first U2F key, so I doubt random increments were even a thing back then.
@ topic
I think too that an application should get a note about a too high counter, but only alongside an acknowledgement of whether the sig was checked and if yes whether it's true/false, which may depending on how the fun is written not always fly, as many would probably say to do the "easy" validations first to not waste resources, and basically say "if the counter is too low I won't even sig-check.
This is for the simple reason that if one wants to go a hardline approach like to grill the access with the U2F stick after a low counter, which can result in a DoS for that user if abused, one wants to be sure that an actual threat is happening before potentially locking the user out completely. and not just a script kiddie which just wants to annoy people as much as possible, also the counter check probably isnt going to help against a cloned key anyway as an attacker can just set the number REALLY high and they are in, and while a lock can happen after the real user logs in with their real key, the attacker probably already got access to the account and did all sorts of BS, so it's too late.
so a counter check in general would be best done IN MY OPINION in a way that the library cant play alone.

directly after registration, let the user complete a few authentications (if it's no problem from a crypto perspective one could even keep the same challenge a few times for simplicity and just store the responses seperately before sending them all together towards the server)

compare the counters of the auths and figure out a "safe" value for increase per auth (maybe double the avg of all of them or whatever) and set a number of missed auths as a "safe distance", for example a max of 5 missed auths per day the key wasnt used and a max of 100 auths.

if a user logs in with a Key that has a counter beyond the safe count (but the sig checks out), first deny the login and lock the key, while then sending a message to the user by whatever means and inform him about the counter and that the stick may just have been used a lot on other sites between logins on that site, and that he should check his U2F stick for tampering ASAP and that if he had the U2F stick on himself while the login occured to best erase that U2F stick from all sites they use it, and if he indeed was it, provide a means to unlock the stick (e.g. by logging in with a different second factor and then doing an auth on the locked stick

hi @My1
Yes, the counter-rolled-back lockout should only occur after the signature checks out.
If there's any keys using the epoch as counter, this would, by my read, break the spec. The purpose of the counter is to ensure that two identical (cloned) keys cannot exist concurrently. If you use one, the other should fall behind, or if the bad one is used the good one should fall behind. The purpose of this counter is that it makes it nearly impossible to do some u2f 'master key' nonsense and clone keys around the room.  Thats its practical purpose. Its primarily a mechanism to prevent the credential sharing which we see with totp seeds all the time.
So it needs to be implemented in such a way that this goal is achieved. That a rollback event is detected, and if the signature is valid, it should lock the account as if the credential had been improperly shared.
One solution for the non-conforming alter-keys would be to define rules for Yubikeys only (checking the attestation cert) and agree that no Yubikey will ever generate 2^32 u2f signatures in its lifetime when touch-policy is enabled. In that way rules that make sense for specific hardware could be designed. Similarly if a key is known to (wrongly) use epoch as the counter, then that epoch should be confirmed as in range (1 hour?)... and so forth.
In any event this bug dates from 2014 and was never fixed, and with WebAuthN moving forward, I suspect this lib will be retired shortly. Lets hope they fix it in the new sdk. ;)

epoch as a counter, wtf who had that idea? also, HOW when there are no batteries etc.
the keys I know which increase more than 1, also only increase on each interaction but by an iirc more or less semi-random amount (which basically is supposed to make it harder to track the yubis). the whole idea with my lockout idea was just a quick idea which could use heuristics and stuff to go with how many counter increases can be expected between logins, where obviously time is a factor because most users log in a few times more in a month than in a week, obviously.
the problem with a pure "counter too low" lockout is that the cloned key can gain access once, which often is one time too much as it already allows to do a lot to the account in question, and THAT is one of the big problems.
With my little idea basically for the hacker, they would have to know where the counter roughly is and in which ballpark the increase per action roughly is, so time for an example:
if I use a key which has a strict "+1 per auth" (with the service being aware of that) and have set a maximum of 10 unseen auths per day with a max of 100 auths total, the attacker has a lot less luck the more recently a key has been used, after all he needs to get the key but also hope that the victim doesnt notice and knocks the key out, but within a single day you would need to have the counter with in 10 of the value the service has last seen in order to not raise the suspicion of the service and to temp-lock the key, which leads to the user noticing and then removing that key everywhere.

this may make some attacks at least a bit harder because as said an attacker cant just go and set the counter to a million or whatever and get in.

Nice to know I can render U2F keys denied by having hammered authentication commands and overflow that counter, thanks for the cheap implementation

@sanawu I think you can go into overflow that easily. the counter iirc only is increased if your U2F device actually does an Auth and not just a request.
Let's get the base math out: the U2F counter is 32 bytes unsigned (imo a bit little for long term but sure), that makes the max counter 2^32-1 or the safe max counter considering some languages really dont like processing unsigned numbers as 2^31-1, or 2.147.483.647.
assuming a normal U2F/Fido2 device with a global counter (meaning counter starts at zero, no backup or other places where you can play counter shenanigans) with an average increment of 300 per auth and let's say 10 uses a day that would be 3k on the counter per day, this is almost 716k days, leading to almost 1960 years, that should last a few lifetimes.
Even if I go Webdev and use the thing 100 times in a day as a kinda reasonable number we would still be 196 years about double what most humans live.

also what do you exactly mean with denying sending incremented counters right after saying that assuming good RPs is the problem?
the RP does not have anything to say about the counter except the "last seen" counter for the interaction between itself and the U2F devices. the actual counter lives in the U2F device, and in incremented in there every time the user does a successful auth as far as the device is concerned (aka every time it makes a signature), the most you can do as an RP is to deny a user his login at your site, but that's something you can do anyway as a website, no need for U2F with that.

also yes it doesnt exactly prevent cloning but most things called tamperproof nowadays is totally not tamper proof but tamper evident. like moment a low counter error with a proper signature is seen, you as a user can know that something is going on.
and if users use proper safety precautions and have either a backup key or backup method, then cloning and raising a single key's counter wont deny them anything, bonus fact, a few comments above I noted a defense against exactly this type of attack.

also what do you mean with "we have a fingerprint" thing? you mean Devices like the Trustkey G-Series (formerly eWBM Goldengate) with fingerprint readers, sorry but that data doesnt flow through Fido2.
The only thing that flows here is basically the fact that the FP has been checked (or more generally speaking that the device in some form or another verified its user) via a bitflag (aka true/false, that's it) so as said already, nothing for an RP to grab in here.


Missing scroll bar when starting the recipe

Bug description
I am starting a recipe on (ie. rag chatbot) on Linux, and since there is a quite a lot of steps to perform, the screen is full and I do not see directly the OpenDetails or bottom part of the Start a recipe Page. And there is no scroll bar. So I need to zoom out to get the rest of info.
With default zoom (roughly):

After zoom out:

Operating system
Linux
Installation Method
None
Version
next (development version)
Steps to reproduce
No response
Relevant log output
No response
Additional context
No response

This is not reproducible on Mac

It is, the banner regarding GPU is causing this misalignment. If you go to Preferences and disalbed GPU (so it appears again) I can see the problem constantly.


[Bug] Check for EXIF orientation data on profile picture uploads and handle accordingly

More info: http://sylvana.net/jpegcrop/exif_orientation.html


Deduplicate attribution events in analytics database (original #629)

This issue has been migrated from the CC Search api repository
Author: annatuma
Date: Tue Sep 29 2020
Labels: 🏷 status: label work required,🙅 status: discontinued

We found an issue in the frontend, where we are triple counting attribution events:
https://github.com/creativecommons/cccatalog-frontend/issues/1231
Once this is fixed, we'll need to go through historical data to deduplicate attribution events, to ensure they're correct historically as well.

Original Comments:
zackkrida commented on Sep 29, 2020:

Noting that the tripled events from the front-end are concurrent, so should all have very similar or even identical timestamps in our db, which could be an easy way to handle deduping.
source

Closing this issue because we have removed the analytics server.


[Microsoft] fix reading OpenID Connect token responses

when using Microsoft's OpenID Connect service (as documented at
https://azure.microsoft.com/en-us/documentation/articles/active-directory-v2-protocols/)
if you only request the openid scope, Microsoft only returns an id_token,
with no access_token. so treat that as a valid response.

I've run into the same issue. I left some comments to help fix the build and then hopefully this could get some attention from 👍

I've updated the PR with your suggestions.

Any movement on getting this merged @ccutrer?

I'd almost forgotten this PR existed. I've just been updating our monkey patch in our app with each bump of this gem. I'll update the PR

PR updated with conflicts resolved, and specs passing.

Pull Request Test Coverage Report for Build 827

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at ?%

Totals

Change from base Build 826:
0.0%

Covered Lines:

Relevant Lines:
0

💛  - Coveralls

Pull Request Test Coverage Report for Build 827

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at ?%

Totals

Change from base Build 826:
0.0%

Covered Lines:

Relevant Lines:
0

💛  - Coveralls

Pull Request Test Coverage Report for Build 827

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at ?%

Totals

Change from base Build 826:
0.0%

Covered Lines:

Relevant Lines:
0

💛  - Coveralls

Pull Request Test Coverage Report for Build 827

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at ?%

Totals

Change from base Build 826:
0.0%

Covered Lines:

Relevant Lines:
0

💛  - Coveralls

I know this is an old PR but is there any advice on how to use Microsoft responses that only hav id_token in the. This fix make that a valid response but the AccessToken class still expects the access_token in the response hash.
What's the fix? Is it to subclass AccessToken ?

Thansk @jonspalmer I afraid extending AccessToken is the only option for now. I see you found https://github.com/oauth-xx/oauth2/pull/511 already, we could move conversation on it for a completely solution for this.


Turbo daemon creates / leaves a ton of <defunct> processes, accumulating enough sometimes to breach the OS-wide process limit, preventing the creation of any new processes.

Verify canary release

[X] I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue
I think: all turbo projects running turbo while in interactive-rebase.
This is a pretty bad bug, because MacOS only has a limit of ~ 5600 processes, and once you hit that, you can't spawn terminals, can't open apps, can't create new tabs in the browser, can't run ps, even.
You have to have already had activity monitor (or similar) open so that you can kill the turbo daemon process. Else you may be forced to reboot.
Which canary version will you have in your reproduction?
2.3.1-canary.0
Enviroment information
❯ pnpm turbo info
turbo 2.3.1-canary.0

CLI:
   Version: 2.3.1-canary.0
   Path to executable<EMAIL_ADDRESS>   Daemon status: Running
   Package manager: pnpm9

Platform:
   Architecture: aarch64
   Operating system: macos
   WSL: false
   Available memory (MB): 10455
   Available CPU cores: 12

Environment:
   CI: None
   Terminal (TERM): alacritty
   Terminal program (TERM_PROGRAM): unknown
   Terminal program version (TERM_PROGRAM_VERSION): unknown
   Shell (SHELL): /opt/homebrew/Cellar/bash/5.2.32/bin/bash
   stdin: false

Setup, check processes:
ps -ef | grep defunct | wc -l
# 1 or 2

Normally, an OS should be around < 1000 processes:
ps -ef | wc -l
# I usually hover around 600 to 800

Scenario A (inconsistent)

be in interactive rebase
(I'm splitting commits into more commits)
have prepare or postinstall trigger turbo's build
run turbo again (maybe for lint, or whatever)

Scenario B (inconsistent)

after changing a dependency of a package

Test:
ps -ef | grep defunct | wc -l
# 807

Test after upgrading to latest canary (noting that we run build in postinstall):
❯ ps -ef | grep defunct | wc -l
#    1435

I have an ongoing monitor for this running every second in a terminal that I just leave up all the time.
❯ watch -n 1 "echo \"All: \$(ps -ef | wc -l), Defunct: \$(ps -ef | grep defunct | wc -l)\""

And with pstree we can see that these all come from turbo
# get a list of all unique parent processes for each defunct process
❯ ps -ef | grep defunct | awk '{print $3}' | sort -u

# pass each of these to pstree
while IFS= read -r pid; do
    pstree -p $pid
done <<< $(ps -ef | grep defunct | awk '{print $3}' | sort -u)

Which will print something like this:
-+= 00001 root /sbin/launchd
 \-+= 11557 $USER /opt/homebrew/opt/borders/bin/borders
   \--- 11558 $USER <defunct>
-+= 00001 root /sbin/launchd
 \-+= 43271 $USER<EMAIL_ADDRESS>--skip-infer daemon
   |--- 43359 $USER <defunct>
   |--- 43361 $USER <defunct>
   # and a few many hundred more
   \--- 57042 $USER <defunct>

Expected behavior
no defunct processes exist ever, as the OS will not halt these.
Actual behavior
defunct processes are left laying around.
To Reproduce
It's possible this is reproducible in these OSS repos:

https://github.com/nullvoxpopuli/limber
https://github.com/universal-ember/ember-primitives

I somewhat regularly have to kill the top level turbo daemon on Linux due to CPU usage -- but it's maybe possible that the reason for that is the same root reason that is causing me to observe the behavior that has resulted in me reporting this issue for MacOS.
In both cases, Linux (where I do most of my OSS) and Mac (where I do my closed-source employer-owned work), Killing the turbo daemon processes immediately makes any of my machines happier -- cleaning up defunct processes (macos) or freeing up cpu cycles (linux)
Additional context
No response

If either of you could share daemon logs (turbo daemon status should display the logfile) that would be helpful. We should not be spawning child processes from the daemon.

Here is what I got:
❯ pnpm turbo daemon status
# ...
✓ daemon is running
log file: <repo>/.turbo/daemon/e224a4a441d772ef-turbo.log.2024-11-19
uptime: 16m 6s 566mss
pid file: /var/folders/wk/w99lck4x7_5930c7gj65r3s40000gp/T/turbod/e224a4a441d772ef/turbod.pid
socket file: /var/folders/wk/w99lck4x7_5930c7gj65r3s40000gp/T/turbod/e224a4a441d772ef/turbod.sock

Which has this content (lots of text)
There was a problem saving your comment. Your comment is too long (maximum is 65536 characters). Please try again.

oops 🙈
here is a file tho
output.txt

It seems this is happening nearly daily for me -- can't really pinpoint what is causing the defunct processes to show up. In Activity Monitor, I do occasionally see > 20 git processes spawn, and then go away -- maybe related? idk.

We are trying setting https://turbo.build/repo/docs/reference/configuration#daemon to false for the time being. 🤞

It seems this is happening nearly daily for me -- can't really pinpoint what is causing the defunct processes to show up. In Activity Monitor, I do occasionally see > 20 git processes spawn, and then go away -- maybe related? idk.

Thank you so much for this comment! I didn't realize the daemon shelled out to git and there was in fact a bug where those git processes weren't getting reaped.
We should be correctly reaping child git processes with https://github.com/vercel/turborepo/pull/9564 which is being released in 2.3.4-canary.1 which I will cut today. I would greatly appreciate if you could test it out.

Thanks, @chris-olszewski !
I've tested with 2.3.4-canary.2
and had a control as well to verify defunct processes were still getting created (yay git worktrees!)
So far, I've not seen any defunct processes spawn from the canary.2
pending
Process

I'm watching total process count vs defunct count via
watch -n 1 "echo \"All: \$(ps -ef | wc -l), Defunct: \$(ps -ef | grep defunct | wc -l)\""

looks like this:

The command I'm running is pnpm build --no-cache --force so turbo actually does stuff 😉 (too efficient otherwise!). We have a wrapper CLI that mixes in some environment variables, flags, and handles whether or not to reach out to the remote cache with a custom AWS S3 SSO
pnpm turbo --color --no-update-notifier \
  --env-mode=loose --summarize=true --output-logs=new-only \
  _:build \ # We use a _: prefix because we need to define "build" in the package.json, but also want `build` in each package to go through turbo
  --filter=./libraries/**/* --no-cache --force

In my two branches, I've removed "daemon": false from the turbo.json at the root of the repo

I'm running the pnpm build --no-cache --force command 4 times to make sure behavior is consistent. Each time I run it, I make note of the total processes before and after, as well as defunct processes.

Starting with a fresh rebase on the main branch so I don't have any local caches, deleted node_modules, etc
# once
killall turbo
git fetch origin

# each branch / worktree
get rebase origin/default-branch-name
nuke # local recursive clean script here:  https://github.com/NullVoxPopuli/dotfiles/blob/323173c6042882a17079bccca7149985038dd1b6/home/scripts/bash-support/aliases.sh#L8
pnpm install # runs an initial build via postinstall

Results
Baseline env

All Processes
Defunct Processes

659
6

Note that total process count will fluctuate a bit, because the OS does do things. 🙈
The following tables will use the format [starting process count, ending process count]
example: [659, 656] would mean that before I ran the build command, we started with 659 total processes and ended up with 656)
control branch with turbo @ 2.3.3
expected outcome: defunct processes spawn

Run
All Processes
Defunct Processes

1
[657, ]
[6, ]

1
[657, ]
[6, ]

1
[657, ]
[6, ]

1
[657, ]
[6, ]

branch with turbo @ 2.3.4-canary.2
expected outcome: defunct process count does not grow at all, for the entirety of the duration of the command

Run
All Processes
Defunct Processes

1
[657, ]
[6, ]

1
[657, ]
[6, ]

1
[657, ]
[6, ]

1
[657, ]
[6, ]

I need to wait for one of my worktrees to reproduce the issue before I collect data.
Been trying to re-create the situation manually, but it's clear I still don't know the right order operations to reproduce the defunct spawning problem.

Awesome work, folks. Thank you, @NullVoxPopuli, for your thoroughness.


Access http://localhost:8081 only prints "Ok"

Following your instructions I was able to run the emulator:
C:\passkeys-demo>npm run emulator

><EMAIL_ADDRESS>emulator
> firebase emulators:start --only firestore --project passkeys-demo --import=./.data --export-on-exit

i  emulators: Starting emulators: firestore
i  firestore: Importing data from C:\passkeys-demo\.data\firestore_export\firestore_export.overall_export_metadata
i  firestore: Firestore Emulator logging to firestore-debug.log
+  firestore: Firestore Emulator UI websocket is running on 9150.
i  ui: Emulator UI logging to ui-debug.log

┌─────────────────────────────────────────────────────────────┐
│ ✔  All emulators ready! It is now safe to connect your app. │
│ i  View Emulator UI at http://<IP_ADDRESS>:4000/               │
└─────────────────────────────────────────────────────────────┘

┌───────────┬────────────────┬─────────────────────────────────┐
│ Emulator  │ Host:Port      │ View in Emulator UI             │
├───────────┼────────────────┼─────────────────────────────────┤
│ Firestore │ <IP_ADDRESS>:8081 │ http://<IP_ADDRESS>:4000/firestore │
└───────────┴────────────────┴─────────────────────────────────┘
  Emulator Hub running at <IP_ADDRESS>:4400
  Other reserved ports: 4500, 9150

Issues? Report them at https://github.com/firebase/firebase-tools/issues and attach the *-debug.log files.

I also run the following command:
PS C:\passkeys-demo> npm run dev

><EMAIL_ADDRESS>dev
> set NODE_ENV=localhost node server.mjs
PS C:\passkeys-demo>

But when I access localhost on port 8081 I only get "Ok":

Never mind,
I was able to run it when I simply run node server.mjs and then access port 8080.
It seems that I had some issue with the run dev command.


Debug for php

Issue Type: Feature Request
I can't put breakpoints in a .php file, I can't debug my php code
VS Code version: Code 1.52.0 (940b5f4bb5fa47866a54529ed759d95d09ee80be, 2020-12-10T22:45:11.850Z)
OS version: Windows_NT x64 10.0.18363

Same problem. Clicking on the left margin does to add a new breakpoint.
Please correct the "Issue Type" as it is a Bug, not a feature request.

Indeed, PHP breakpoints do not work anymore with November 2020 release (1.52).
Need to downgrade to October 2020 release (1.51).

no need to downgrade. Just see this workaround: https://github.com/microsoft/vscode/issues/112288#issuecomment-743456329

/duplicate #112288

no need to downgrade. Just see this workaround: #112288 (comment)

Yes, the breakpoint indicator shows in the gutter, but it does not get hit during debugging.


Job disappears after canceling on mobile view

Current behavior

On mobile devices, after canceling a job, the job details disappear from the page

Attaching video for reference as well
https://user-images.githubusercontent.com/60128132/235671820-be9a1ee0-4770-4daf-b1a1-43012c8c32ad.MOV

This is happening on desktop as well. Just noticed yesterday.


Add custom font

First of all, thank you very much for this awesome tool guys, it's really amazing.
Something that i would like to change is the default font and some styles about the mdx. Do you know if is it possible?
Thanks!!

For sure! Since Nextra is on top of Next.js, you can check this out: https://nextjs.org/docs/basic-features/font-optimization :)
Another way is to have global CSS: https://nextjs.org/docs/basic-features/built-in-css-support


Fix path.exists output

as of penlight 1.14.0, path.exists(P) return P if it exists, false otherwise. In particular, path.exists(P)==true is always false.

Thank you for catching this! This appears to be the case in 1.13.1 too, so I'll merge it in now.
https://github.com/lunarmodules/Penlight/blob/1.13.1/lua/pl/path.lua#L155


feat(API): Add 'default_encoding' documentation

Documentation for https://github.com/phrase/phrase/pull/14383/

@BlumMichael is the param also exposed via the show project endpoint and should be documented here?

@BlumMichael is the param also exposed via the show project endpoint and should be documented here?

It's not exposed via show-endpoint: https://github.com/phrase/phrase/blob/STRINGS-843-follow-up/app/serializers/project_serializer.rb

@BlumMichael i think we should then also add it to the project show endpoint? if users want to set it they probably also want to check the current state :)

@theSoenke create too, I guess?

@BlumMichael i think we should then also add it to the project show endpoint? if users want to set it they probably also want to check the current state :)

@theSoenke
None of the other settings (e.g. "smart_suggest_enabled", "enable_branching", "autotranslate_enabled", and so on) are available on the show endpoint. While I agree that it might be useful to have them there, I think it is out of scope for this ticket. Maybe lets create a separate task for that?
Example show-call
http://localhost:3000/api/v2/projects/6033a78e0e993a15409ec9d18fa93bb2
{
    "id": "6033a78e0e993a15409ec9d18fa93bb2",
    "name": "Strings-563",
    "slug": "strings-563",
    "main_format": "strings_json",
    "media": "",
    "shares_translation_memory": true,
    "project_image_url": null,
    "created_at": "2024-10-29T06:29:08Z",
    "updated_at": "2024-12-12T10:08:11Z",
    "account": {
        "id": "c1d4a2bcaa4aa8b8a0ec9f5cf23cc322",
        "name": "Phrase2",
        "slug": "phrase",
        "company": "",
        "created_at": "2024-08-08T06:31:46Z",
        "updated_at": "2024-12-10T08:51:17Z",
        "company_logo_url": null
    },
    "branch": null,
    "space": null,
    "point_of_contact": {
        "id": "66d2f0e1b74143a05630e79c9f4b0912",
        "username": "michael.blum+1000",
        "name": "Michael Blum",
        "gravatar_uid": "8c6376c873fdf69071a979f8e4be01b5"
    }
}


read_timeout option ignored

While debugging another timeout issue, I noticed read_timeout isn't used anywhere in the code:
https://github.com/uber/vertica-python/search?q=read_timeout&type=Code
(it's only setting the default value, but the option isn't used anywhere and the other mention is in the README).

I also encountered this issue. I'm working on a fix for this. I think in the meantime the read_timeout parameter should be removed. It is confusing for users who set this parameter to something other than 600 and then see that it doesn't change anything.

@HaymanLiron That's great, thank you for your help!

I recently also hit this issue. My use case requires two timeouts, one for establishing connection with Vertica and one for waiting to query response. When the Vertica node is healthy, there is no reason to have 2 timeouts but when client tries to connect to node with some issue (TCP socket still open but Vertica node does not respond to it) it is more than useful. And yes, we hit this unlikely scenario several times during HW malfunction.
@sitingren Are there any plans to support two timeouts?
And what about easier timeout identification by proper use of already existing errors.TimedOutError
Additionally, I think that issue #83 could be linked with this one because it discuss another aspect of query timeout, i.e. it is only client side error and query continues running on server side. It would be nice to have interruptable flag like ruby implementation has. I would vote for extending ruby functionality by reestablishing session and calling close_session() just after query timeout in case connection was created with interruptable flag or may by query_cleanup flag.
@HaymanLiron Any progress with implementation of the fix? How exactly do you plan to add support for read_timeout? Do you preserve connection_timeout?

@pcerny I agree to use existing errors.TimedOutError and I also think it's better to rename 'connection_timeout' option to a more accurate name.
As of today, the 'connection_timeout' option is actually setting socket timeout, which means it sets the maximum wait time for:

Establishing a TCP connection to each server address.
A single call to socket read/write operation (socket.recv(), socket.sendall()).

Therefore, the 'connection_timeout' option acts on both vertica_python.connect() (i.e. establishing connection with Vertica) and cursor.execute() (i.e. waiting to query response). Currently, 1&2 set to the same value but it is possible to separate them. Will this meet your needs?
We propose to have the following two timeouts:

connect_timeout/login_timeout: the maximum time spent waiting for the client connects to the server, which includes the time to try establishing TCP connections to multiple addresses if load balancing is turned on, the time to setup ssl, the time to setup authentication, etc.
query_timeout: the maximum time spent waiting for a query to finish. This timeout should send a cancel command to the server to cancel that session's query while the socket is still open.

They may intersect with the socket timeout and increase the complexity. As far as I know, there are timeout decorator tools that can be utilized to wrap functions and achieve the goal of those timeouts somewhat. We'll definitely clear up misunderstandings about existing parameters soon, but adding new timeouts might not be our top-priority task.


Android CI changes

Seems reasonable! What happens when the PR changes only iOS code yet the Android build workflow check is required to merge PRs?

Seems reasonable! What happens when the PR changes only iOS code yet the Android build workflow check is required to merge PRs?

Great question. Couldn't find a good way to do that and it seems that statuses are simply stuck like on this PR.
If this becomes a problem I guess we can disable check requirements and use common sense / require more reviews when merging.
Maybe even a github action that approves a PR when statuses it deems necessary have passed.

Great question. Couldn't find a good way to do that and it seems that statuses are simply stuck like on this PR.
If this becomes a problem I guess we can disable check requirements and use common sense / require more reviews when merging.
Maybe even a github action that approves a PR when statuses it deems necessary have passed.


just get rid of it

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

ah yes this is a good idea

 All committers have signed the CLA.


Handles cases where the view_context cannot be used to generate collection links in the RTLShowPresenter

Resolves #522

Coverage increased (+0.4%) to 100.0% when pulling fb4ed0d7149d7ad86005fce5f4003f2c1eabe040 on issues-522-jrgriffiniii-exhibit-root-path-fix into 35a9dfd4e2240fc770805498182ec8e2c52410b4 on master.


menu not working with scrollable

When the MenuBar is in scrollable and the scrollable is scrolled (not at the top) the menu doesn't work.
working example (I have included whole cargo.toml and main.rs for easier test):
[package]
name = "aw_menu_scrollable"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
iced = "0.8.0"
iced_aw = { version = "0.4.1", default-features = false, features = ["menu"] }

use iced::{Element, Error, Length, Sandbox, Settings};
use iced::widget::{button, container, scrollable, text, column};
use iced_aw::menu::{MenuBar, MenuTree};

struct App;

#[derive(Debug, Clone)]
pub enum AppMessage {
    Something
}

impl Sandbox for App {
    type Message = AppMessage;

    fn new() -> Self {
        App
    }

    fn title(&self) -> String {
        String::from("test")
    }

    fn update(&mut self, message: Self::Message) {
        match message {
            AppMessage::Something => {
                // nothing
            }
        }
    }

    fn view(&self) -> Element<'_, Self::Message> {
        scrollable(
            container(
                column![
                    container(MenuBar::new(vec![
                        MenuTree::with_children(
                            button("Lorem").on_press(AppMessage::Something),
                            vec![
                                MenuTree::new(button("Edit").width(Length::Fill).height(Length::Fill).on_press(AppMessage::Something)),
                                MenuTree::new(button("Delete").width(Length::Fill).height(Length::Fill).on_press(AppMessage::Something))
                            ]
                        ).width(100)
                    ])).width(Length::Fill).center_x().padding(50),
                    container(text("something in between")).height(1000).center_x(),
                    container(MenuBar::new(vec![
                        MenuTree::with_children(
                            button("Lorem").on_press(AppMessage::Something),
                            vec![
                                MenuTree::new(button("Edit").width(Length::Fill).height(Length::Fill).on_press(AppMessage::Something)),
                                MenuTree::new(button("Delete").width(Length::Fill).height(Length::Fill).on_press(AppMessage::Something))
                            ]
                        ).width(100)
                    ])).width(Length::Fill).center_x().padding(50),

                ]
            )
        ).into()
    }
}

fn main() -> Result<(), Error> {
    App::run(Settings::default())
}

sounds like a issue for @latidoremi

seems I forgot to take into account the parent offset for the layouts

this might take a while, drawing and different events have their own way of reasoning about layout, simply offsetting them doesn't work

@CristianKerr could you checkout the code in the linked pr see if it fixes the issue

@latidoremi I will try to do it tomorrow if I have time

@latidoremi I appologize, I still didn't get to it. I will try to do it asap, but right now I have before release at work and I am drained in the evenings.

@CristianKerr It is fine test it when you can.  @latidoremi already tested it with the code you posted and it seems to be working. If there is any other issue later on just let us know.


Uncaught -32602: Invalid params

[Enter steps to reproduce below:]

set breakpoint with F9
hit F9 again

Atom Version: 1.2.4
System: Mac OS X 10.10.5
Thrown From: dartlang package, v0.4.17
Stack Trace
Uncaught -32602: Invalid params
At /Users/sethladd/.atom/packages/dartlang/web/entry.dart.js:21314

-32602: Invalid params
    at [object Object].dart.wrapException (/Users/sethladd/.atom/packages/dartlang/web/entry.dart.js:22336:17)
    at _rootHandleUncaughtError_closure.dart._rootHandleUncaughtError_closure.call$0 (/Users/sethladd/.atom/packages/dartlang/web/entry.dart.js:41645:19)
    at _AsyncCallbackEntry.dart._AsyncCallbackEntry.callback$0 (/Users/sethladd/.atom/packages/dartlang/web/entry.dart.js:40519:30)
    at [object Object].dart._microtaskLoop (/Users/sethladd/.atom/packages/dartlang/web/entry.dart.js:39342:12)
    at [object Object].dart._microtaskLoopEntry (/Users/sethladd/.atom/packages/dartlang/web/entry.dart.js:39348:11)
    at TimerImpl_internalCallback0.dart.TimerImpl_internalCallback0.call$0 (/Users/sethladd/.atom/packages/dartlang/web/entry.dart.js:21664:23)
    at invokeClosure_closure.dart.invokeClosure_closure.call$0 (/Users/sethladd/.atom/packages/dartlang/web/entry.dart.js:23504:29)
    at _IsolateContext.dart._IsolateContext.eval$1 (/Users/sethladd/.atom/packages/dartlang/web/entry.dart.js:21305:25)
    at [object Object].dart._callInIsolate (/Users/sethladd/.atom/packages/dartlang/web/entry.dart.js:20949:28)
    at dart.invokeClosure (/Users/sethladd/.atom/packages/dartlang/web/entry.dart.js:22484:18)
    at /Users/sethladd/.atom/packages/dartlang/web/entry.dart.js:22505:18

Commands
     -5:33.7.0 settings-view:check-for-package-updates (atom-workspace.workspace.scrollbars-visible-always.theme-one-dark-syntax.theme-one-dark-ui)
  2x -4:54.2.0 core:close (div.panels-item)
  3x -4:00.3.0 core:backspace (atom-text-editor.editor.is-focused)
     -3:55.3.0 core:save (atom-text-editor.editor.is-focused)
     -3:52.9.0 dartlang:run-application (atom-text-editor.editor.is-focused)
     -3:06.9.0 editor:newline (atom-text-editor.editor.is-focused)
     -3:04.8.0 core:save (atom-text-editor.editor.is-focused)
     -3:03.3.0 core:close (atom-text-editor.editor.is-focused)
     -3:01.9.0 dartlang:run-application (atom-text-editor.editor.is-focused)
  3x -0:19.9.0 dartlang:debug-toggle-breakpoint (atom-text-editor.editor.is-focused)

Config
{
  "core": {
    "disabledPackages": [
      "dart-tools"
    ]
  },
  "dartlang": {
    "sdkLocation": "/Users/sethladd/homebrew/opt/dart/libexec",
    "showOutlineView": false,
    "flutterSdkLocation": "/Users/sethladd/Code/flutter"
  }
}

Installed Packages
# User
dartlang, v0.4.17
highlight-selected, v0.11.1
last-cursor-position, v0.9.0
linter, v1.11.3
minimap, v4.16.2

# Dev
No dev packages

Seems repeatable, put cursor on line, hit F9, then hit F9 again.

fixed in https://github.com/dart-atom/dartlang/pull/651


Ubuntu 22.10: Ctrl+O, Open File, and Audio Select do not open file explorer

I'm on GNOME 43, and clicking any button that should open file explorer just doesn't open the file explorer, making the application effectively useless. Especially if I want to launch it with my graphics card enabled, meaning I can't select the "open with" option.
Here's the log output when running from the terminal:

Fixed in the latest release


How to convert the generated model (.pt file) to safetensors

I'm testing train dreambooth with lora, the generated model is in .pt format, also with a json config file. If I want to add this lora model to Automatic1111 WebUI. How to make it run? How to convert the model to safetensors format?

Anyone can help me? The .pt file and config .json file are generated after I run the train_dreambooth.py script.


Write down setup instructions

Write down the instructions step by step for dev experience

I can work on this as initial task.


Please update the old document about navigation drawer

Description of the Bug
Navigation Drawer document contains "NavigationLayout" which is named as "MDNavigationLayout" on new update(s).
Edit on GitHub option also not working too


Update README.md

the template did not work for me, then i found the solution in your blog,

Thanks, these instructions can be useful indeed.


Add description for new warning C26826

@dmitrykobets-msft
Thanks, Dmitry. Does this warning appear starting in a particular version of VS? That is, is it in VS 2019 version 16.11 (or earlier), or does it require VS 2022?

@corob-msft The warning is implemented in 17.1 Preview 1, and the VS-side of the changes were merged into main on October 12.

@corob-msft : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Add json2yaml

🙏 ✨

I added some commits to kick GitHub actions, as it was hanging for > 17 hours