Bump word-wrap from 1.2.3 to 1.2.4 #150
Conversation
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
Bumps [word-wrap](https://github.com/jonschlinkert/word-wrap) from 1.2.3 to 1.2.4. - [Release notes](https://github.com/jonschlinkert/word-wrap/releases) - [Commits](jonschlinkert/word-wrap@1.2.3...1.2.4) --- updated-dependencies: - dependency-name: word-wrap dependency-type: indirect ... Signed-off-by: dependabot[bot] <[email protected]>
dependabot
bot
added
the
dependencies
|
As of the latest available information, Halcyon is at version 0.9.45, last updated on June 15, 2021. As of the current date, September 14, 2023, there have been no further updates, and it remains unclear who is currently responsible for its development. Ricky appears to have paused his involvement with Halcyon for the time being, while Bob, who manages the website, is encountering issues with bugs. Bob also expects compensation for assistance. Suggestions for improving Halcyon seem to be met with resistance from Bob. For instance, there's a notable difference in how inventory archives (IAR) and object archives (OAR) are handled. Loading an OAR is straightforward without requiring a password; you simply type ">load oar test.oar," and it loads on everyone's grid, regardless of its origin. In contrast, loading and saving an IAR involves a more complex command, ">load iar !" Bob argues that IAR isn't necessary, citing safety concerns, but it's essential to retain IAR. To address the complexity issue with OAR commands, a proposal suggests a more user-friendly structure: ">load oar <oar.test> <OAR version 0.8>." The inclusion of "Grids Name" enhances security by preventing OARs from being imported into another grid. For IAR, the proposed command is: ">load iar ." This maintains security while simplifying the command structure. Lastly, it's recommended to remove all obsolete Open Sim code to enhance security and ease of installation. If you have any questions or need further information, please feel free to contact Ana Green and my Dad Frank Orbis at [email protected]. |
|
IAR's are not supported in the Halcyon codebase. There is skeletal support but they were NEVER fully implemented. Hence the reason you probably are getting told they're not necessary. Another thing to note, Its been a year since I last worked on it and since then more changes have been introduced that will break in current Firestorm. Profiles and groups wont function correctly. The Estate handling is incorrect. And none of the now being developed materials support will work. In short pretty much the only viewer that will work is the old InWorldz viewer at this point. Halcyon is obsolete. There is no active development and at this stage its more sensible to move components in Halcyon to current OpenSIm Core or NGC than to try and update Halcyon to current standards. |
|
I hope that Ana Green's message that is me provides a clear and concise assessment of the limitations and issues with Halcyon: "Regarding Halcyon, it's important to note that ARs (Abuse Reports) have never functioned within the platform. This has led some to believe that AR functionality is not a high priority. Furthermore, there are notable incompatibilities with the OAR (Object Archive) format, making it challenging to transfer content to OpenSim without encountering various issues. It's essential to emphasize that there appears to be a lack of development interest in addressing these issues. I can confidently state, based on years of experience with Halcyon, that the platform has undergone further changes rendering it incompatible with current software. For instance, the current version of Firestorm is incompatible with Halcyon. Profiles and group functionalities are dysfunctional, and estate management features are also broken. Additionally, new materials support seems unlikely to function. In light of these challenges, it's crucial to acknowledge that Halcyon's development seems to have ceased. The potential for its technology to find its way into OpenSim Core or NGC is uncertain, but it appears that Halcyon has reached a dead end. I recently attempted to enhance security, a key concern for Halcyon users. However, I encountered a significant security issue: compressed OAR files lack password protection, allowing for the unauthorized use of OARs from other grids on one's own. In contrast, IARs (Inventory Archive) at least required a username and password for access, but this security measure has been removed. This raises serious security concerns. I proposed the reintroduction of IAR functionality and suggested an alteration to the OAR archive format. Specifically, I recommended adding the originating grid's name and the grid owner's username to the archive. This modification would restrict content imports to the same grid, preventing access from other grids. While these changes are not currently supported, they could potentially improve security. In summary, Halcyon's development came to an abrupt halt with the conclusion of Inworldz. It's important to recognize that Halcyon was originally designed for a single world, Inworldz, rather than multiple worlds. Consequently, little effort was put into making it easy to install. I recall discussing this with David Daeshler, who stated that making Halcyon easy to install was not a priority task. Best regards, |
|
I might start with the IAR code and the new OAR code and post it here so that it is easy to implement into the base code from Halcyon that would be end of this year or so, also I am working on an easy to install process using an GUI, 3 months later I will start with a PHP based website what operators can quickly set up using an GUI or manual that is their choice and May 2024 I will give a look at the Firestorm. Profiles and groups functions, after May that same year if I have time I'll take all Opensim dead code out or use Vinhold Starbrook his great website with his ideas, he is really working hard on it. Best Refards, |
|
Why a password in an OAR file, Mister Vinhold calls it a waste of time. In unequivocal terms and with a scientific perspective, it's imperative to clarify the distinction between a region owner and a grid owner. A region owner has ownership rights restricted to their specific region within a grid, while a grid owner exercises ownership over the entire grid itself. When a grid owner runs the grid on a hosted server, they possess comprehensive control over all aspects of the grid's operation. The concept of an OAR (OpenSim Archive) file parallels that of conventional compressed file formats such as ZIP, RAR, or ARC. An OAR file serves as a container that encapsulates a region's content and settings. Notably, an OAR file can be extracted and applied to any compatible grid, even if the OAR file does not originate from the individual extracting it. Distinguishingly, an IAR (Inventory Archive) file is designed to be stored within an individual's inventory and functions similarly to password-protected compressed files like ZIP or RAR. An IAR file, akin to its counterparts, includes a username and password for access. It is worth noting that this approach is reminiscent of instances in which entire regions from platforms like Second Life were expropriated and subsequently redistributed in the form of OAR files. The ease of utilization stems from the open nature of OAR files, enabling widespread accessibility. If you perceive the idea of password protection for OAR files as an inefficient use of time and effort, it's essential to contemplate the rationale behind why other compressed file formats are afforded password protection. Password protection adds an additional layer of security, ensuring that only authorized individuals can access and extract the contents of a compressed file. In the context of OAR files, this could potentially enhance security and control over the distribution and usage of region data. Ultimately, the decision to implement password protection for OAR files hinges on factors such as security requirements, user preferences, and the specific use case within the virtual world environment. Ana Green |
|
The OpenSimulator Archive (OAR) functionality has been a part of OpenSimulator since version 0.5.9. This feature serves a function analogous to the load-xml2/save-xml2 functions, as it allows for the preservation of prims for later retrieval. However, the distinction lies in the comprehensive capabilities of OpenSimulator archives (OAR). OAR goes a step further by not only preserving prims but also encapsulating all the requisite asset data. This includes the ability to fully restore terrain, region parcel data, object textures, and their associated inventories, even when loaded onto an entirely different system utilizing a distinct asset database. It has come to my attention that certain individuals may not advocate for robust data protection measures for OAR files, such as password protection and encryption. While Halcyon Grids have opted not to use Inventory Archive (IAR), originating from Opensim's lineage, there is a compelling argument to enhance security by incorporating encryption for data within an inventory archive. Furthermore, it would be prudent to apply similar security measures to OAR files in Opensim environments. It's important to emphasize that this security consideration is not necessarily viewed as a superfluous endeavor by Opensim developers. Initially, I was convinced that a higher level of security for password-protected OAR files was warranted. Given the prevalence of both Halcyon Grids and Opensim Grids, unauthorized use of any obtained OAR file poses a real concern. As the owner of a Grid, it's relatively straightforward to manipulate permissions and access levels through the viewer. However, as of the present date, September 21, 2023, I have decided to discontinue the creation of password-protected archives, specifically Opensim Archives (OAR), for Halcyon Grids. I invite you to explore and utilize some of the available OAR files for your region from the following source: Link to OAR Files With this statement, I convey that this will be my final proposal for implementing enhanced security measures in Halcyon environments, as it appears that the chosen approach may differ from the perspective of the Halcyon development community. Sincerely, Ana Green |
Bumps word-wrap from 1.2.3 to 1.2.4.
Release notes
Sourced from word-wrap's releases.
Commits
f64b188run verb to generate README03ea082Merge pull request #42 from jonschlinkert/chore/publish-workflow420dce9Merge pull request #41 from jonschlinkert/fix/CVE-2023-26115-2bfa694eUpdate .github/workflows/publish.ymlace0b3cchore: bump version to 1.2.46fd7275chore: add publish workflow30d6dafchore: fix test655929cchore: remove package-lock49e08bbchore: added an additional testcase9f62693fix: cve 2023-26115Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)You can disable automated security fix PRs for this repo from the Security Alerts page.