Activation Icon Packager Full Version 12
Thibaut Silverman
I'd like to do the latter everywhere, and I see I can choose icons in this matter when editing a content type in the back office, however I am using a modified version of USiteBuilder and a code first approach to my content types.
I suspect maybe LaxyLoad does it's own minification, so rejects anything with .min in the filename maybe? Which could be bad, because minifying things can break if not done specific ways. E.g. some js files are designed to be minified with a custom builder, like is popular with node.js -> npm and grunt etc, so preventing someone from using their already minified script could break their setup.
But good you figured out another way to achieve it - actually there is a couple of font packages released and the latest is font-awesome, which can be fetched here -extensions/font-awesome-icon-pack-and-media-icons - It might be relevant for others who may come across this issue.
Icon names equal those on the official website, but are written in lower camel case. If more than one icon style is available for an icon, the style name is used as prefix, except for "regular".Due to restrictions in dart, icons starting with numbers have those numbers written out.
We supply a configurator tool to assist you with common customizations to this package.All options are interoperable.By default, if run without arguments and no icons.json in lib/fonts exists, it updates all icons to thenewest free version of font awesome.
The configurator is located in the util folder and can be started by running configurator.bat on Windows, or./configurator.sh on linux and mac. All following examples use the .sh version, but work same for .bat.(If on windows, omit the ./ or replace it with .\.)An overview of available options can be viewed with ./configurator.sh --help.
Probably the most requested feature after support for pro icons is the ability to retrieve an icon by their name.This was previously not possible, because a mapping from name to icon would break alldiscussed optimizations. Please bear in mind that this is still the case.As all icons could theoretically be requested, none can be removed by flutter. It is strongly advised to only use thisoption in conjunction with a limited set of styles and with as few of them as possible. You mayneed to build your app with the --no-tree-shake-icons flag for it to succeed.
Flutter 1.22 added icon tree shaking. This means unused icon "images" will be removed as well. However, this onlyapplies to styles of which at least one icon has been used. Assuming only icons of style "regular" are being used,"regular" will be minified to only include the used icons and "solid" and "brands" will stay in their raw, completeform. This issue is being tracked over in the flutter repository.
Update: since publication of this blog, new, malicious packages attributable to the accounts identified in our original report appeared on npm. In addition, new CDN (content distribution network) infrastructure was identified being used for script inclusion. We have updated our blog post to include the latest information and will continue updating it as new threats or information become available. (July 6, 2022)
Can you spot the pattern? A deeper investigation into these npm modules reveals even more connections. All were connected to one of a handful of npm accounts with names like ionic-io; arpanrizki; kbrstore; and aselole.
To figure out what was going on with these packages, our team started by de-obfuscating the package content using a javascript deobfuscator. We followed that with a detailed examination of the de-obfuscated samples, which revealed that all of them perform collection of form data using jQuery Ajax functions, and then exfiltrate that data to various domains controlled by malicious authors. In other words: This is clear evidence of malicious intent.
Clearly, the typosquatting technique used to fool developers into confusing the malicious packages with their legitimate counterparts was working. Packages created by the npm ionic-io author, for example, show that the author published 18 versions of an npm package named icon-package containing the malicious form stealing code. That was a glaring attempt to mislead developers into using this package instead of ionicons, a popular, open-source icon set with more than 1,000 icons for web, iOS, Android, and desktop apps.
Download stats from npm show that the malicious icon-package has over 17,000 downloads. Data exfiltrated using this package passes through a domain hxxps://ionicio.com, a play on the legitimate ionicons framework domain ionic.io that would be easy for application developers to overlook. The ruse extends beyond the npm ecosystem, though. Note the visual similarity between the fake ionic web page seen in Figure 3 and the legitimate ionic page in Figure 4.
Under the hood, the malicious packages use a modified script that extends the behavior of the jQuery ajax() function to exfiltrate serialized form data to domains controlled by the attacker. Prior to sending the data, the function validates the URL content to perform target filtering checks.
In the process of tracing the origin of the campaign, even older packages containing this type of malicious functionality were discovered. They were published in December 2021 by the author fontsawesome, and also targeted the already mentioned ionicons icon set. The domain used for data exfiltration in these packages is the same as the one used in the first two versions of the icon-package package: hxxps://graph-googleapis.com.
While the exact start of this campaign is unknown, the malicious package published from December 2021 all the way to the middle of May 2022 focused on mimicking the ionicons framework. At that point, the attackers switched to developing new npm packages that reused the same functionality and also started targeting other popular UI frameworks.
One of those packages is called umbrellaks, which is an obvious attempt at a typosquatting attack on the quite popular umbrellajs javascript DOM (document object model) manipulation framework.
We also observed several packages published by the npm account arpanrizki engaging in similar form data-grabbing. However, the exfiltration domain associated with these packages is different: hxxps://arpanrizki.my.id. The form identifier for exfiltrated data was quite specific: ValidateVerificationDataForm. So, as part of our investigation, we performed a GitHub search for this identifier, with some interesting results. (See Figure 5.)
As the results show, one of the GitHub repositories containing the string in question were maintained by arpantek, a nickname very similar to the one of the npm author. The other result was related to a HackingTool repository belonging to the npm author Woxruz.
Similarly, the swiper-bundIe package, a malicious npm package targeting the popular Javascript framework swiper, uses the embedded jQuery approach, extending its end() function with functionality that gathers data from every form element on the page.
Finally, the malicious packages use exfiltration domains with a consistent naming pattern: .my.id. Together, these clues suggest a common actor behind the various malicious packages and a unified campaign.
A .nuspec file is an XML manifest that contains package metadata. This manifest is used both to build the package and to provide information to consumers. The manifest is always included in a package.
A .nuspec file is not required to create packages for SDK-style projects (typically .NET Core and .NET Standard projects that use the SDK attribute). (Note that a .nuspec is generated when you create the package.)
If you are creating a package using dotnet.exe pack or msbuild pack target, we recommend that you include all the properties that are usually in the .nuspec file in the project file instead. However, you can instead choose to use a .nuspec file to pack using dotnet.exe or msbuild pack target.
For a clear visual representation of the schema, open the schema file in Visual Studio in Design mode and click on the XML Schema Explorer link. Alternately, open the file as code, right-click in the editor, and select Show XML Schema Explorer. Either way you get a view like the one below (when mostly expanded):
All XML element names in the .nuspec file are case-sensitive, as is the case for XML in general. For example, using themetadata element is correct and is not correct. The proper casing for each element nameis documented below.
Although the following elements are the minimum requirements for a package, you should consider adding the optional metadata elements to improve the overall experience developers have with your package.
The case-insensitive package identifier, which must be unique across nuget.org or whatever gallery the package resides in. IDs may not contain spaces or characters that are not valid for a URL, and generally follow .NET namespace rules. See Choosing a unique package identifier for guidance.
A comma-separated list of packages authors, matching the profile names on nuget.org. These are displayed in the NuGet Gallery on nuget.org and are used to cross-reference packages by the same authors.
A comma-separated list of the package creators using profile names on nuget.org. This is often the same list as in authors, and is ignored when uploading the package to nuget.org. See Managing package owners on nuget.org.
An SPDX license expression or path to a license file within the package, often shown in UIs like nuget.org.If you're licensing the package under a common license, like MIT or BSD-2-Clause, use the associated SPDX license identifier. For example:
A URL for a 128x128 image with transparency background to use as the icon for the package in UI display. Be sure this element contains the direct image URL and not the URL of a web page containing the image. For example, to use an image from GitHub, use the raw file URL like
It is a path to an image file within the package, often shown in UIs like nuget.org as the package icon. Image file size is limited to 1 MB. Supported file formats include JPEG and PNG. We recommend an image resolution of 128x128.
b37509886e