dataesr/scientific-paragraphs-categorization huggingface dataset:
Acknowledgements We thank  Prof. Reinhard Wirth +  ( University of Regensburg ) for fruitful discussions,  Manuela-Raluca Pausan  ( Medical University of Graz ) for proofreading and  Samuel Payler  ( University of Edinburgh ) for providing DNA. We also thank  Thomas Rattei  ( University of Vienna ) for providing computational power at the  LISC cluster. Foundation (ESF), Strasbourg, France. 7Instituto  Nacional de Técnica Aeroespacial -Centro de Astrobiología (INTA-CAB) ,  Madrid, Spain. 8Centro de Biología Molecular Severo Ochoa ,  Universidad Autónoma de Madrid (UAM), Madrid, Spain. 9Leiden Observatory, Universiteit Leiden, Leiden , The Netherlands. 10 MATIS, Reykjavík, Iceland. 11Faculty of  Food Science and Nutrition, University of Iceland, Reykjavik, Iceland. 12Institute of  Environmental Biotechnology, Graz University of Technology, Graz, Austria.
g. , field margins, host plants, etc. ). All these components are selected according to their significance in the explanation of the injury profile of the considered pests. This platform requires the organization of its hierarchy according to a specific plan, implemented with the DEXi software  (Bohanec, 2020). The DEX method, implemented by the software DEXi, supports qualitative hierarchical attribute aggregation. Originally, this method was designed as a decision modeling method based on the subdivision of a complex problem into smaller and less complex subproblems. These subproblems are represented by hierarchically structured attributes, i. e. , variables that characterize the complex problem. Terminal attributes of the hierarchy represent inputs (or input indicators), while the root represents the main output of the model.
Attributes used in the model are qualitative variables, either ordinal or nominal. The use of quantitative variables is not possible directly through the DEXi software, however upstream converters can be designed to discretize quantitative variables before they are used in the model, or to convert nominal variables into ordinal ones (e. g. , the name of a cultivar can be converted into a qualitative level of resistance to a disease). The building process of an IPSIM model requires three steps: (i) identifying and structuring the attributes, (ii) defining attribute scales, and (iii) defining the aggregating tables  (Aubertot and Robin, 2013).
Factors were chosen first according to the literature with keywords involving general and generic growing factors (e. g. , Temperature, Rainfall, Soil, Relative Humidity, Photoperiod) and control methods (e. g. , Competitive crops, Cover crops, Tillage, Cropping practices, etc. ) related to C. arvense. This literature analysis was made using commercial databases (EconLit, Food Science Source, Web of Science, MEDLINE R , Saga Web, Scopus, TAIR) and free databases (Google Scholar, Agricola, ProdINRA, PubMed). The list of beneficial and detrimental factors was then confronted to experts during workshops to co-design the model. The experts were chosen nationally from research institutes (INRAE), technical institutes (Arvalis, Terres Inovia, Acta), and Chambers of Agriculture according to their participation on Cirsium arvense control programs or expertise.
Attribute Scales The following step is to set scale values to each attribute. Aggregated and input attributes of IPSIM-Cirsium have either two or three levels of scale (e. g. , Unfavorable, Moderately favorable, and Favorable). They are represented by words and can be either ordinal or nominal. Unfavorable means that this attribute is detrimental to the user and therefore detrimental to the control of Cirsium arvense (Figure  2 ). This scale order is designed directly under DEXi software and will be prevalent for the establishment of aggregating tables. Scale values are sometimes a result of a conversion of quantitative or qualitative variables. For example, the amount of rain per month is categorized into three levels: Favorable to Cirsium, Moderately Favorable to Cirsium, and Unfavorable to Cirsium.
Aggregating Tables The last step to build an IPSIM model is the definition of aggregative tables for each aggregated attribute and the output of the model. During the aggregation of underlying attributes in the attribute tree, decision rules must be edited to characterize any aggregation possibilities. Collectively, these rules were initially called "Utility functions. " These aggregative rules are simple "if-then" functions that enable the model to provide a specific answer to any situation it is confronted to. Aggregative tables are represented in a tabular form in the DEXi software and aim at considering scale orders of the underlying attributes (Figure  3B ). To consider each aggregation possibility, we consider all the combinations of scale levels of the underlying attributes. For example, Competitiveness of crop is composed of the aggregation of Sown crop and Sowing density.
Data Collection Several datasets (D) were used in the evaluation of the predictive quality of IPSIM-Cirsium, summarized in Table  2. D1 was collected at the INRAE experimental farm in Bretenière (47 • 14' 11. 2" N, 5 • 05'56. 1" E), 15 km southeast of Dijon, France. The complete description of the long-term cropping system experiment (crop sequence and associated management, including intensity of tillage herbicide, use herbicide types, mechanical weeding, etc. ) implemented from 2000 to 2017 was synthesized by  Adeux et al. (2019). The reference cropping system (CS) called S1 was characterized by a 3-year oilseed rapewinter wheat-winter barley rotation, systematic moldboard plowing in summer-autumn and herbicides as sole curative weed     Thomsen et al. , 2015; Weill, 2015  The factor can be beneficial (+) or detrimental (-) to control C.
Selected Attributes and Their Relative Importance Using weight calculation of attributes, each cropping practice and pedoclimate indicator can be described alone according to their importance to evaluate weed infestation. IPSIM-Cirsium, expert and literature-based model correctly reflects the knowledge available to build the model. Cropping practices were chosen to be more relevant in the explanation of Cirsium arvense than the environment of the field. This choice was supported both by literature and expert knowledge. Therefore, whenever cropping practices were rated as Ineffective to control Cirsium arvense, a mild or Favorable climate for the user did not influence the risk of weed infestation that was rated High already. Environment was thus accredited to a low weight by DEXi software, explained by the low number of rules directly influenced by the grade of its scale.
Evaluation of the Predictive Quality By means of the large dataset, gathering many sites and years (220 situations) with a wide diversity of cropping practices and pedoclimates, it was possible to perform a reliable evaluation of the predictive quality of the model. Calculated values of infestation were very similar to the observed values in field, resulting in a satisfactory evaluation (78. 2% of the values were correctly calculated). Figure  4  illustrates the confusion matrix between observed and calculated values of weed infestation. However, square weighted Cohen's kappa reached 0. 543, meaning that slightly more than half of the variability of the observed values were explained by IPSIM-Cirsium. Here, kappa interprets the strength of agreement between calculated and observed values as moderate  (Landis and Koch, 1977; Altman, 1999).
Weed pressure was evaluated by the mean value of all the density of Cirsium arvense observed in the field. To ensure the correct use of IPSIM-Cirsium, Initial level of infestation observed the year preceding the evaluation, it is necessary to assess an average density of Cirsium arvense according to the method widely used for weed pressure calculation in data collection protocol [Chicouène method;  (Chicouene and Arbiotech, 2000) ; random quadrat collection, etc. ]. This requirement can be a limit for the accuracy of the prediction of weed infestation by IPSIM-Cirsium. Still, it is possible for the user of the model to provide a qualitative value of the level of initial infestation without using a quantitative value converted into a qualitative value. This qualitative estimation might bring a bias of subjectivity related to the user appreciation of the infestation severity.
Multi-attribute hierarchical modeling in DEXi software perfectly fits the understanding of the complexity of agroecosystems, by reducing factors to only two to three scale levels. This approach greatly simplifies the conception of innovative agroecosystems by focusing on cropping practices that are directly described as efficient or not, depending on the chosen intensity of the implemented method. The interactions of simplified cropping practices are then described in aggregating tables, giving a new value to the aggregated attribute such as Mechanical control of Cirsium arvense. This value provides to the user a direct indicator of performance of the considered aggregated cropping practice. It is easier for the user to consider all the cropping practices instead of focusing on the improvement of one single practice that may not be sufficient to control weeds, even at high intensity.
FUNDING Work in our group was funded by grants from the French National Research Agency (MetDePaDi ANR-16-CE16-0012), the Institut National du Cancer (PLBIO 2018-149), the Fondation pour la Recherche Médicale (FRM), and Fondation Bettencourt-Schueller to TG. NS is recipient of a fellowship from the University de Paris -CD4Impact international program (ANR-18-IDEX-0001).
Open source packages have source code available on repositories for inspection (e. g. on GitHub) but developers use pre-built packages directly from the package repositories (such as npm for JavaScript, PyPI for Python, or RubyGems for Ruby). Such convenient practice assumes that there are no discrepancies between source code and packages. These differences pose both operational risks (e. g. making dependent projects unable to compile) and security risks (e. g. deploying malicious code during package installation) in the software supply chain. Our empirical assessment of 2438 popular packages in PyPI with an analysis of around 10M lines of code shows several differences in the wild: modifications cannot be just attributed to malicious injections. Yet, scanning again all and whole 'most likely good but modified' packages is hard to manage for FOSS downstream users.
The key idea is to support mechanisms for lightweigth and scalable screenings applicable automatically to the entire population of software components by Machine intelligent identification of security issues, Sound analysis and verification of changes, Business insight by risk analysis and security evaluation. This approach supports fast-paced development of better software by a new notion: continuous (re)certification. The project will generate also benchmark datasets with thousands of vulnerabilities. AssureMOSS: Open Source Software: Designed Everywhere, Secured in Europe. More information at https://assuremoss. eu. Antonino Sabetta (Phd 2007) is a senior researcher at SAP Security Research. He is the Technical Leader of the AssureMOSS project and the "Continuous analysis and correction of secure code" work package leader.
INTRODUCTION The expression software supply chain refers to "anything that goes into or affects your code from development, through your CI/CD pipeline, until it gets deployed into production"  [22]. In the past decade, Free and Open-Source Software (FOSS) has become an integral part of the software supply chain: as much as 99% of codebases contain open-source code  [43] , and 85%  [41]  to 97%  [47]  of enterprise codebases comes from open source. One benefit of FOSS is that source code and additional metadata is publicly available for audit, review, and even modification. Developers rely on this information (e. g. , number of GitHub stars, number of downloads from libraries. io) to decide whether to add a FOSS project as a software dependency into their projects  [25, 35]. Organizations with high security requirements, e.
g. , government organizations or vendors of commercial enterprise software, commonly establish vetting processes to ensure the quality and security of 3rd party software and services  [9, 31]. In the case of FOSS, this evaluation is performed mostly by manual reviews and automated scans of the source code repository of each dependency  [10]. In theory, once code is checked, developers could download software dependencies as source files in tarballs, and build them in-house. Yet, this process can be time-consuming and requires knowledge of the build systems  [21]. In practice, developers download pre-built packages from repositories (such as npm for JavaScript, PyPI for Python, or RubyGems for Ruby) under the comfortable assumption  that no discrepancies are introduced in the last mile between the source code and their respective packages.
Yet, such discrepancies might be introduced by manual or automated build tools (e. g. , metadata, Python bytecode files)  [18]  or for evil purposes. For example, a backdoor was inserted into the PyPI package ssh-decorate to collect the users' SSH credentials and exfiltrate them to a remote server  [7]. Reproducible builds could be a solution. For it to be practical, modifications need to be the exception rather than the norm. Unfortunately, the opposite is true on the field. Indeed, in the npm ecosystem, packages are not easily reproducible from the source code  [18]. The same applies to the PyPI ecosystem (see  Section 6). In the absence of reproducible builds, a vetting process must be extended to cover the risk of malicious code injection in the last mile. Since applications have many direct and transitive dependencies, and because every new version has to be verified, scalability and integration with existing security review pipelines are key.
These requirements clash with the resources at hand for FOSS repositories: less than ten PyPI administrators oversee 400 000 package owners. At the time of writing, for every new upload, PyPI's vetting pipeline only checks a script called setup. py for malicious code that would execute upon package installation  [52]. Although setup. py is commonly targeted by attackers, malicious code is also injected other locations. Other approaches also require a significant effort to reduce false positives  [13]  and to improve the quality of hand-crafted signatures  [32]. While suspicious packages or updates might be flagged, too many false alerts are generated for benign packages  [29]. In 2020, the administrators had to evaluate 1874 new updates per day, with an average of 3500 files generated by more than 76 997 developers  [6].
Thus, the cost of even a single false positive in the evaluation must be multiplied by those numbers. A key observation is that in code injection attacks, only a minimal part of the codebase is modified  [49]. One could simply focus on the last mile differences between the source code and the submitted packages. Hence our first question: • RQ1: Can we effectively and efficiently identify differences? A basic solution already exists: git log. For each line in an artifact, we check whether it is (or at least was) in the repository at some point. By iterating over all commits (revisions), we ensure that we collect everything in the source code repository, and we eliminate the need for identifying the pair of Git release/tag and PyPI release to be compared. Unfortunately, that does not scale as git log needs to loop over all revisions and spawns a heavy git process each time it is invoked.
We could also use diffing techniques  [2, 18] , but they require a mapping of each PyPI release onto the corresponding Git tag or release, which does always exist. Our algorithm LastPyMile is a feasible alternative to this problem. By cleverly combining package scraping and artifact hashing, we can extract these differences in a scalable way. Then, we can analyze how big is the gap in the field: • RQ2: How big are the 'normal' differences between source code and package repositories? We show that for more than 2000 popular packages in the PyPI ecosystem, such differences are pervasive. If a package code differs from the published source code, one cannot assume that it has been maliciously modified. Differences are too many (65% of artifacts and 22% of files in our sample) and too diverse for reproducible builds to be a solution.
Yet, only few modifications happen in Python source files (2. 6% of files) so that vetting might be a feasible alternative. Finally, we can try to determine whether this solution can make a difference on the end goal: improving the vetting and coverage of scanners while keeping the number of false alerts manageable for PyPI maintainers given the imbalance ratio between the PyPI maintainers and the number of packages  [50]. • RQ3: Can LastPyMile be combined with package scanners while keeping the number of alerts manageable by a human? To be effective in the field, we should allow developers and development organizations to use the same tools to scan the source code repository of a package as part of their vetting process. Without protecting their investments in licenses, workflows, and developer education, an excellent technical solution would be doomed to fail.
BACKGROUND 3. 1 The Last Mile from Source to Package Figure  1  shows a typical package process of releasing a Python package in PyPI that consists of three main stages: development, build and distribution, and security review. The primary activities of the development stage mainly happen at a source code repository (e. g. , GitHub, GitLab, Bitbucket, etc. ). At this stage, developers write all the code of a project. Developers may run various tools to test the functionality of the project and the absence of security vulnerabilities. If a project is open-source, other people could access the code, check it, and suggest improvements. The source code repository is often an essential source of information for the developers to decide the quality of a software  [35]. When developers decide to make the software version available for other people (i.
e. , make a release), they move the code to the build stage. At this stage, automated tools such as Travis CI, Jenkins, AppVeyor, or GitHub Actions use the information stored in the project configuration files to build it. These tools fetch the source code of the package and execute the build scripts that collect all the necessary dependencies, add package metadata, generate code (e. g. , Swagger Codegen), and create artifacts that are ready to be distributed, like source archives, Linux, or Windows binaries, test coverage logs, and documentation. At the publication stage, developers upload the artifacts to a package repository (e. g. , PyPI, npm, Maven Central) either manually or automatically by using the build tool from the packaging stage. Most consumers will actually use the version of the software stored and published via package repositories.
Uploaded artifacts need to go through the security review stage of a package repository. In PyPI, PyPI administrators run multiple checks (see Subsection 3. 4) on uploaded artifacts. The checks will generate a verdict if an uploaded artifact contains suspicious behavior. The administrators are then reviewing the verdicts to decide to keep the artifact. The match between the source code version of a project and the packages that correspond to that version is taken for granted  [35]. However, several tools (and humans) are involved at different stages of the pipeline, and some actions may result in a published artifact containing code that is not present in the source code repository. During the packaging stage, building tools add metadata files and augment existing code files (e. g. , setup.
py) with information  [3] , such as license, timestamp 3  , release version, etc. Developers also use tools such as Swagger Codegen that automatically generate code files (e. g. , server stubs and client SDKs for APIs). Developers may also change the code of a published artifact directly to backport a bug or a vulnerability fix  [50]. Developers' actions might create difficulties to connect the distributed artifacts and their source code repositories (Figure  2 ). Example 1. The PyPI page of package robotframework-selenium2library points to the GitHub repository robotframework/SeleniumLibrary that contains the code for the releases before v1. 8. 0 and after v3. 0. 0a1. The code for other releases is stored in a different GitHub repository robotframework/Selenium2Library. In this example, comparing a specific package version on PyPI with the corresponding GitHub tag for the releases in between v1.
Software Supply Chain Attacks Software supply chain attacks occur when malicious or vulnerability is injected into differnt stages of the software development chain  [20, 26]. Ohm et al. studied several attacks on different ecosystems  [33]  and found hijacking and typosquatting attacks to be the most common. Compromising the package owner's credentials would allow attackers to inject malicious payloads into the existing artifacts so that users will download and install them. Some examples of attacks are the injection of backdoors into PyPI ssh-decorate package  [1] , Ruby rest-client package, or npm even-stream   package  [19]. Attackers can commit malicious code into a source code repository  [17, 37]. Package name *-squatting attacks are more prevalent than package hijacking  [33]. In typo-and combosquatting attacks  [33, 50]  adversaries inject a malicious payload into the code of a popular package.
Then they release this new package with a name nearly identical to the name of the original package to trick package users who mistype the package name and install the malicious one. This attack becomes especially attractive considering the limited automatic controls integrated into the package publishing process, and the certain unbalance concerning the number of package users and PyPI Administrators/Moderators (40K to 1)  [53]. 4 Several attempts were made to identify the typo-and combosquatting packages present in the package managers  [4, 42, 45, 50]. Example 2. A typosquatting PyPI package urlib3 [40] impersonated the popular package urllib3. 5  urlib3 contains malicious code to exfiltrate user information to a remote server. urlib3 has a single release urlib3-1. 21. 1. tar and the same Github URL as urllib3.
Reproducible Builds as an Ideal Solution Reproducible builds  [11]  is a set of development practices that create an independently verifiable path from source to published artifacts. They could be the ideal solution to verify that no vulnerabilities or backdoors have been introduced during the build process. However, to achieve the reproducibility of the build process, we must eliminate varying elements in release pipelines. For example, builds should not include any CPU, timestamp, or locale information in distributed artifacts  [18]. Hence, reproducible builds require a significant overhaul in the languagebased package managers such as PyPI or npm  [3, 18]  because current release pipelines augment packages with more information, such as metadata, debug data, or automatically generated code files (See Section 3.
Current PyPI Packages Scanners Table  2  summarizes the existing tools that support identifying malicious code injections in Python packages. Several scanning tools  [5, 13]  parse files into abstract syntax trees (AST) and perform rule-based searches on their nodes. Application-Inspector  [28]  and OSSGadget  [29]  use regular expressions to identify suspicious code lines. However, the tool authors mention that their tools generate many false positives if run on the entire package code  [29]. This high number of false positives is to be expected. 1 # Establishing a socket connection to a server 2 s = socket. socket(socket. AF_INET, socket. SOCK_STREAM) 3 rip = 'M' + 'TIxL' + 'jQyL' + 'jIx' + 'N' + 'y4' + '0NA' + → '==' 4 # Sending the encoded data via the socket 5 s. connect((base64. b64decode(rip), 017620)) Listing 1: Malicious code snippet opening of a socket to an encoded network address.